On Thu, Nov 30, 2017 at 3:30 PM, Fengguang Wu <fengguang...@intel.com> wrote: > On Thu, Nov 30, 2017 at 05:29:09PM +0900, Sergey Senozhatsky wrote: >> >> On (11/30/17 09:16), Dmitry Vyukov wrote: >> [..] >>> >>> > to be honest, this backtrace hardly makes any sense to me. >>> > >>> > vprintk_emit() >>> > reserve_standard_io_resources() >>> > __flush_tlb_all() >>> > vprintk_emit() >>> > __down_trylock_console_sem() >>> > wake_up_klogd() >>> > console_unlock() >>> > >>> > I need some help here. >>> >>> >>> You can try dirty patch from here: >>> https://groups.google.com/d/msg/kasan-dev/iDb5bhcMBT0/55QzwWaHAwAJ >>> It should make KASAN print the exact variable name and frame where it >>> was allocated. >> >> >> would be good if Fengguang can try this out. I can't reproduce the >> problem on my x86 box (linux-next and Linus's trees both work fine >> for me with KASAN + lockdep + TRACE_IRQ). > > > Attached is the dmesg with Dmitry's patch. The new output is: > > [ 0.003333] frame offset: 32 > [ 0.003333] desc: '2 32 4 3 __u 96 8 3 __u ' > [ 0.003333] func: console_unlock+0x0/0xcc0
Thanks for testing. The output looks broken. There are more than 2 variables in console_unlock. Probably it has found a wrong stack frame descriptor on stack... But Andrey says that use-after-scope has known false positives with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y, so probably this does not matter.