linux-kernel - Re: [BUG] KCSAN: data-race in xas_clear_mark / xas_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <873686fb-6e42-493d-2dcd-f0f04cbcb0c0@alu.unizg.hr>
Date:   Fri, 18 Aug 2023 15:37:10 +0200
From:   Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org
Subject: Re: [BUG] KCSAN: data-race in xas_clear_mark / xas_find_marked

On 8/18/23 14:21, Matthew Wilcox wrote:
> On Fri, Aug 18, 2023 at 10:01:32AM +0200, Mirsad Todorovac wrote:
>> [  206.510010] ==================================================================
>> [  206.510035] BUG: KCSAN: data-race in xas_clear_mark / xas_find_marked
>>
>> [  206.510067] write to 0xffff963df6a90fe0 of 8 bytes by interrupt on cpu 22:
>> [  206.510081]  xas_clear_mark+0xd5/0x180
>> [  206.510097]  __xa_clear_mark+0xd1/0x100
>> [  206.510114]  __folio_end_writeback+0x293/0x5a0
>> [  206.520722] read to 0xffff963df6a90fe0 of 8 bytes by task 2793 on cpu 6:
>> [  206.520735]  xas_find_marked+0xe5/0x600
>> [  206.520750]  filemap_get_folios_tag+0xf9/0x3d0
> Also, before submitting this kind of report, you should run the
> trace through scripts/decode_stacktrace.sh to give us line numbers
> instead of hex offsets, which are useless to anyone who doesn't have
> your exact kernel build.
> 
>> [  206.510010] ==================================================================
>> [  206.510035] BUG: KCSAN: data-race in xas_clear_mark / xas_find_marked
>>
>> [  206.510067] write to 0xffff963df6a90fe0 of 8 bytes by interrupt on cpu 22:
>> [  206.510081] xas_clear_mark (./arch/x86/include/asm/bitops.h:178 ./include/asm-generic/bitops/instrumented-non-atomic.h:115 lib/xarray.c:102 lib/xarray.c:914)
>> [  206.510097] __xa_clear_mark (lib/xarray.c:1923)
>> [  206.510114] __folio_end_writeback (mm/page-writeback.c:2981)
> 
> This path is properly using xa_lock_irqsave() before calling
> __xa_clear_mark().
> 
>> [  206.520722] read to 0xffff963df6a90fe0 of 8 bytes by task 2793 on cpu 6:
>> [  206.520735] xas_find_marked (./include/linux/xarray.h:1706 lib/xarray.c:1354)
>> [  206.520750] filemap_get_folios_tag (mm/filemap.c:1975 mm/filemap.c:2273)
> 
> This takes the RCU read lock before calling xas_find_marked() as it's
> supposed to.
> 
> What garbage do I have to write to tell KCSAN it's wrong?  The line
> that's probably triggering it is currently:
> 
>                          unsigned long data = *addr & (~0UL << offset);

Hi, Mr. Wilcox,

Thank you for your evaluation of the bug report.

I am new to KCSAN. I was not aware of KCSAN false positives thus far, so my best bet was to report them.

I thought that maybe READ_ONCE() was required, but I will trust your judgment.

I hope I can find this resolved.

Best regards,
Mirsad Todorovac