On Thu, Mar 1, 2018 at 4:19 PM, Sergey Senozhatsky <[email protected]> wrote: > On (03/01/18 09:51), Dmitry Vyukov wrote: >> > https://marc.info/?l=linux-kernel&m=151200883525299 >> > >> > [..] >> >> I feel lost a bit. >> > >> > Yeah... can't understand what's going on there. >> > >> > The last time kasan didn't like this part >> > >> > [ 0.003333] ? console_unlock+0x605/0xcc0: >> > atomic_read at >> > arch/x86/include/asm/atomic.h:27 >> > (inlined by) static_key_count at >> > include/linux/jump_label.h:191 >> > (inlined by) static_key_false at >> > include/linux/jump_label.h:201 >> > (inlined by) trace_console_rcuidle at >> > include/trace/events/printk.h:10 >> > (inlined by) call_console_drivers at >> > kernel/printk/printk.c:1556 >> > (inlined by) console_unlock at >> > kernel/printk/printk.c:2233 >> > >> > complaining that there was a write of size 4... at atomic_read(). >> >> Hi Sergey, >> >> Where is that report? >> I doubt that KASAN has instrumented a read as a write (at least there >> are no such known cases), so perhaps it's pointing to some other >> memory access. > > Hello Dmitry, > > I believe it's this one > > https://marc.info/?l=linux-kernel&m=151200883525299
Thanks, but now that I debugged this one, I think that one is the same issue. Amusingly a write in READ_ONCE is actually legitimate because GCC_PLUGIN_STRUCTLEAK emits an initializing write for __u variable in READ_ONCE implementation.
