lkml.org 
[lkml]   [2018]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [lkp-robot] [printk] c162d5b433: BUG:KASAN:use-after-scope_in_c
On Thu, Mar 1, 2018 at 4:19 PM, Sergey Senozhatsky
<sergey.senozhatsky@gmail.com> 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.

\
 
 \ /
  Last update: 2018-03-01 16:54    [W:0.067 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site