Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

KMSAN doesn't work with CONFIG_UNWINDER_ORC #48

Closed
ramosian-glider opened this issue Nov 29, 2018 · 3 comments
Closed

KMSAN doesn't work with CONFIG_UNWINDER_ORC #48

ramosian-glider opened this issue Nov 29, 2018 · 3 comments

Comments

@ramosian-glider
Copy link
Member

$SUBJ
When built with UNWINDER_ORC, the kernel freezes after the line "Starting KernelMemorySanitizer".
ramosian-glider pushed a commit that referenced this issue Dec 5, 2018
@johnstultz-work
wlcore: Fixup "Add support for optional wakeirq"
b630806 
After commit 3c83dd5 ("wlcore: Add support for optional
wakeirq") landed upstream, I started seeing the following oops
on my HiKey board:

[    1.870279] Unable to handle kernel read from unreadable memory at virtual address 0000000000000010
[    1.870283] Mem abort info:
[    1.870287]   ESR = 0x96000005
[    1.870292]   Exception class = DABT (current EL), IL = 32 bits
[    1.870296]   SET = 0, FnV = 0
[    1.870299]   EA = 0, S1PTW = 0
[    1.870302] Data abort info:
[    1.870306]   ISV = 0, ISS = 0x00000005
[    1.870309]   CM = 0, WnR = 0
[    1.870312] [0000000000000010] user address but active_mm is swapper
[    1.870318] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[    1.870327] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 4.19.0-05129-gb3d1e8e #48
[    1.870331] Hardware name: HiKey Development Board (DT)
[    1.870350] Workqueue: events_freezable mmc_rescan
[    1.870358] pstate: 60400005 (nZCv daif +PAN -UAO)
[    1.870366] pc : wl1271_probe+0x210/0x350
[    1.870371] lr : wl1271_probe+0x210/0x350
[    1.870374] sp : ffffff80080739b0
[    1.870377] x29: ffffff80080739b0 x28: 0000000000000000
[    1.870384] x27: 0000000000000000 x26: 0000000000000000
[    1.870391] x25: 0000000000000036 x24: ffffffc074ecb598
[    1.870398] x23: ffffffc07ffdce78 x22: ffffffc0744ed808
[    1.870404] x21: ffffffc074ecbb98 x20: ffffff8008ff9000
[    1.870411] x19: ffffffc0744ed800 x18: ffffff8008ff9a48
[    1.870418] x17: 0000000000000000 x16: 0000000000000000
[    1.870425] x15: ffffffc074ecb503 x14: ffffffffffffffff
[    1.870431] x13: ffffffc074ecb502 x12: 0000000000000030
[    1.870438] x11: 0101010101010101 x10: 0000000000000040
[    1.870444] x9 : ffffffc075400248 x8 : ffffffc075400270
[    1.870451] x7 : 0000000000000000 x6 : 0000000000000000
[    1.870457] x5 : 0000000000000000 x4 : 0000000000000000
[    1.870463] x3 : 0000000000000000 x2 : 0000000000000000
[    1.870469] x1 : 0000000000000028 x0 : 0000000000000000
[    1.870477] Process kworker/0:0 (pid: 5, stack limit = 0x(____ptrval____))
[    1.870480] Call trace:
[    1.870485]  wl1271_probe+0x210/0x350
[    1.870491]  sdio_bus_probe+0x100/0x128
[    1.870500]  really_probe+0x1a8/0x2b8
[    1.870506]  driver_probe_device+0x58/0x100
[    1.870511]  __device_attach_driver+0x94/0xd8
[    1.870517]  bus_for_each_drv+0x70/0xc8
[    1.870522]  __device_attach+0xe0/0x140
[    1.870527]  device_initial_probe+0x10/0x18
[    1.870532]  bus_probe_device+0x94/0xa0
[    1.870537]  device_add+0x374/0x5b8
[    1.870542]  sdio_add_func+0x60/0x88
[    1.870546]  mmc_attach_sdio+0x1b0/0x358
[    1.870551]  mmc_rescan+0x2cc/0x390
[    1.870558]  process_one_work+0x12c/0x320
[    1.870563]  worker_thread+0x48/0x458
[    1.870569]  kthread+0xf8/0x128
[    1.870575]  ret_from_fork+0x10/0x18
[    1.870583] Code: 92400c21 b2760021 a90687a2 97e95bf9 (f9400803)
[    1.870587] ---[ end trace 1e15f81d3c139ca9 ]---

It seems since we don't have a wakeirq value in the dts, the wakeirq
value in wl1271_probe() is zero, which then causes trouble in
irqd_get_trigger_type(irq_get_irq_data(wakeirq)).

This patch tries to address this by checking if wakeirq is zero,
and not trying to add it to the resources if that is the case.

Fixes: 3c83dd5 ("wlcore: Add support for optional wakeirq")
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Eyal Reizer <eyalr@ti.com>
Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: linux-wireless@vger.kernel.org
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ramosian-glider pushed a commit that referenced this issue Aug 27, 2019
@dianders @gregkh
kgdboc: disable the console lock when in kgdb
81eaadc 
After commit ddde3c1 ("vt: More locking checks") kdb / kgdb has
become useless because my console is filled with spews of:

WARNING: CPU: 0 PID: 0 at .../drivers/tty/vt/vt.c:3846 con_is_visible+0x50/0x74
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1+ #48
Hardware name: Rockchip (Device Tree)
Backtrace:
[<c020ce9c>] (dump_backtrace) from [<c020d188>] (show_stack+0x20/0x24)
[<c020d168>] (show_stack) from [<c0a8fc14>] (dump_stack+0xb0/0xd0)
[<c0a8fb64>] (dump_stack) from [<c0232c58>] (__warn+0xec/0x11c)
[<c0232b6c>] (__warn) from [<c0232dc4>] (warn_slowpath_null+0x4c/0x58)
[<c0232d78>] (warn_slowpath_null) from [<c06338a0>] (con_is_visible+0x50/0x74)
[<c0633850>] (con_is_visible) from [<c0634078>] (con_scroll+0x108/0x1ac)
[<c0633f70>] (con_scroll) from [<c0634160>] (lf+0x44/0x88)
[<c063411c>] (lf) from [<c06363ec>] (vt_console_print+0x1a4/0x2bc)
[<c0636248>] (vt_console_print) from [<c02f628c>] (vkdb_printf+0x420/0x8a4)
[<c02f5e6c>] (vkdb_printf) from [<c02f6754>] (kdb_printf+0x44/0x60)
[<c02f6714>] (kdb_printf) from [<c02fa6f4>] (kdb_main_loop+0xf4/0x6e0)
[<c02fa600>] (kdb_main_loop) from [<c02fd5f0>] (kdb_stub+0x268/0x398)
[<c02fd388>] (kdb_stub) from [<c02f3ba0>] (kgdb_cpu_enter+0x1f8/0x674)
[<c02f39a8>] (kgdb_cpu_enter) from [<c02f4330>] (kgdb_handle_exception+0x1c4/0x1fc)
[<c02f416c>] (kgdb_handle_exception) from [<c0210fe0>] (kgdb_compiled_brk_fn+0x30/0x3c)
[<c0210fb0>] (kgdb_compiled_brk_fn) from [<c020d7ac>] (do_undefinstr+0x180/0x1a0)
[<c020d62c>] (do_undefinstr) from [<c0201b44>] (__und_svc_finish+0x0/0x3c)
...
[<c02f3224>] (kgdb_breakpoint) from [<c02f3310>] (sysrq_handle_dbg+0x58/0x6c)
[<c02f32b8>] (sysrq_handle_dbg) from [<c062abf0>] (__handle_sysrq+0xac/0x154)

Let's disable this warning when we're in kgdb to avoid the spew.  The
whole system is stopped when we're in kgdb so we can't exactly wait
for someone else to drop the lock.  Presumably the best we can do is
to disable the warning and hope for the best.

Fixes: ddde3c1 ("vt: More locking checks")
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20190725183551.169208-1-dianders@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
@dvyukov dvyukov mentioned this issue Feb 7, 2020
Merged
@ramosian-glider
Copy link
Member Author

ramosian-glider commented Jul 20, 2021 •
edited 

(gdb) bt
#0  __msan_poison_alloca (address=0xffffffff91403640, size=24, descr=0xffffffff91596160 "----c@stack_trace_save") at mm/kmsan/kmsan_instr.c:159
#1  0xffffffff819dfa91 in stack_trace_save (store=store@entry=0xffffffff91403698, size=size@entry=1, skipnr=skipnr@entry=1) at kernel/stacktrace.c:115
#2  0xffffffff82439b11 in kmsan_internal_return_address (arg=-1856413344, arg@entry=1) at mm/kmsan/kmsan.c:509
#3  0xffffffff82439f57 in __msan_poison_alloca (address=0xffffffff91403730, size=24, descr=0xffffffff91596160 "----c@stack_trace_save")
    at mm/kmsan/kmsan_instr.c:167
#4  0xffffffff819dfa91 in stack_trace_save (store=store@entry=0xffffffff91403788, size=size@entry=1, skipnr=skipnr@entry=1) at kernel/stacktrace.c:115
#5  0xffffffff82439b11 in kmsan_internal_return_address (arg=-1856413344, arg@entry=1) at mm/kmsan/kmsan.c:509
#6  0xffffffff82439f57 in __msan_poison_alloca (address=0xffffffff91403820, size=24, descr=0xffffffff91596160 "----c@stack_trace_save")
    at mm/kmsan/kmsan_instr.c:167
#7  0xffffffff819dfa91 in stack_trace_save (store=store@entry=0xffffffff91403878, size=size@entry=1, skipnr=skipnr@entry=1) at kernel/stacktrace.c:115
#8  0xffffffff82439b11 in kmsan_internal_return_address (arg=-1856413344, arg@entry=1) at mm/kmsan/kmsan.c:509
#9  0xffffffff82439f57 in __msan_poison_alloca (address=0xffffffff91403910, size=24, descr=0xffffffff91596160 "----c@stack_trace_save")
    at mm/kmsan/kmsan_instr.c:167
#10 0xffffffff819dfa91 in stack_trace_save (store=store@entry=0xffffffff91403968, size=size@entry=1, skipnr=skipnr@entry=1) at kernel/stacktrace.c:115
#11 0xffffffff82439b11 in kmsan_internal_return_address (arg=-1856413344, arg@entry=1) at mm/kmsan/kmsan.c:509
#12 0xffffffff82439f57 in __msan_poison_alloca (address=0xffffffff91403a88, size=40, descr=0xffffffff915db070 "----ac@__alloc_pages")
    at mm/kmsan/kmsan_instr.c:167
#13 0xffffffff822ea600 in __alloc_pages (gfp=73728, order=0, preferred_nid=0, nodemask=0x0 <fixed_percpu_data>) at mm/page_alloc.c:5186
#14 0xffffffff823bfecb in alloc_pages (gfp=gfp@entry=73728, order=order@entry=0) at mm/mempolicy.c:2272
#15 0xffffffff8242a2c4 in alloc_slab_page (flags=73728, node=-1, oo=..., s=<optimized out>) at mm/slub.c:1661
#16 allocate_slab (s=s@entry=0xffff888014832800, flags=0, node=node@entry=-1) at mm/slub.c:1801
#17 0xffffffff8240db0c in new_slab (s=0xffff888014832800, flags=<optimized out>, node=-1) at mm/slub.c:1864
#18 new_slab_objects (s=0xffff888014832800, flags=3520, node=<optimized out>, pc=<optimized out>) at mm/slub.c:2610
#19 ___slab_alloc (s=<optimized out>, s@entry=0x92, gfpflags=gfpflags@entry=3520, node=<optimized out>, node@entry=-1, addr=addr@entry=18446744071591563891, 
    c=c@entry=0xffff88807fc99350) at mm/slub.c:2773
#20 0xffffffff82410fe6 in __slab_alloc (s=0xffff888014832800, gfpflags=3520, node=-1, addr=18446744071591563891, c=<optimized out>) at mm/slub.c:2813
#21 slab_alloc_node (s=0xffff888014832800, gfpflags=3520, node=-1, addr=0, orig_size=<optimized out>) at mm/slub.c:2895
#22 slab_alloc (s=<optimized out>, gfpflags=3520, addr=<optimized out>, orig_size=<optimized out>) at mm/slub.c:2938
#23 __kmalloc (size=192, flags=3520) at mm/slub.c:4070
#24 0xffffffff81c21273 in kmalloc (size=192, flags=3520) at /usr/local/google/src/clang-kernel-build/kmsan-devel/./include/linux/slab.h:561
#25 kzalloc (size=192, flags=3264) at /usr/local/google/src/clang-kernel-build/kmsan-devel/./include/linux/slab.h:686
#26 __ring_buffer_alloc (size=4096, flags=1, key=0xffffffff939eb69b <tracer_alloc_buffers..key>) at kernel/trace/ring_buffer.c:1720
#27 0xffffffff935e6625 in tracer_alloc_buffers () at kernel/trace/trace.c:9856
#28 0xffffffff935e6330 in early_trace_init () at kernel/trace/trace.c:9946
#29 0xffffffff9353b5e8 in start_kernel () at init/main.c:939
#30 0xffffffff810000f5 in secondary_startup_64 () at arch/x86/kernel/head_64.S:283
#31 0x0000000000000000 in ?? ()

@ramosian-glider
Copy link
Member Author

I'll leave the bug open, because the output of kmsan_internal_return_address() still differs for ORC and FP unwinders, and one of the tests does not pass. But at least KMSAN doesn't hang anymore.

@ramosian-glider
Copy link
Member Author

Should be fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ramosian-glider