On Mon, Feb 10, 2020 at 10:55:45PM -0500, Qian Cai wrote: > > > > On Feb 10, 2020, at 10:49 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Mon, Feb 10, 2020 at 10:01:34PM -0500, Qian Cai wrote: > >> struct file_ra_state ra.mmap_miss could be accessed concurrently during > >> page faults as noticed by KCSAN, > >> > >> BUG: KCSAN: data-race in filemap_fault / filemap_map_pages > >> > >> write to 0xffff9b1700a2c1b4 of 4 bytes by task 3292 on cpu 30: > >> filemap_fault+0x920/0xfc0 > >> do_sync_mmap_readahead at mm/filemap.c:2384 > >> (inlined by) filemap_fault at mm/filemap.c:2486 > >> __xfs_filemap_fault+0x112/0x3e0 [xfs] > >> xfs_filemap_fault+0x74/0x90 [xfs] > >> __do_fault+0x9e/0x220 > >> do_fault+0x4a0/0x920 > >> __handle_mm_fault+0xc69/0xd00 > >> handle_mm_fault+0xfc/0x2f0 > >> do_page_fault+0x263/0x6f9 > >> page_fault+0x34/0x40 > >> > >> read to 0xffff9b1700a2c1b4 of 4 bytes by task 3313 on cpu 32: > >> filemap_map_pages+0xc2e/0xd80 > >> filemap_map_pages at mm/filemap.c:2625 > >> do_fault+0x3da/0x920 > >> __handle_mm_fault+0xc69/0xd00 > >> handle_mm_fault+0xfc/0x2f0 > >> do_page_fault+0x263/0x6f9 > >> page_fault+0x34/0x40 > >> > >> Reported by Kernel Concurrency Sanitizer on: > >> CPU: 32 PID: 3313 Comm: systemd-udevd Tainted: G W L 5.5.0-next-20200210+ #1 > >> Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 > >> > >> ra.mmap_miss is used to contribute the readahead decisions, a data race > >> could be undesirable. Both the read and write is only under > >> non-exclusive mmap_sem, two concurrent writers could even overflow the > >> counter. Fixing the underflow by writing to a local variable before > >> committing a final store to ra.mmap_miss given a small inaccuracy of the > >> counter should be acceptable. > >> > >> Suggested-by: Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> > >> Signed-off-by: Qian Cai <cai@xxxxxx> > > > > That's more than Suggested-by. The correct way to submit this patch is: > > > > From: Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> > > (at the top of the patch, so it gets credited to Kirill) > > Sure, if Kirill is going to provide his Signed-off-by in the first place, I’ll be happy to > submit it on his behalf. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> -- Kirill A. Shutemov
