[syzbot] [mm?] [fs?] KCSAN: data-race in __filemap_add_folio / invalidate_bdev (8)

[syzbot] [mm?] [fs?] KCSAN: data-race in __filemap_add_folio / invalidate_bdev (8)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    80e54e84911a Linux 6.14-rc6
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1664a7a8580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=958433697845b9a6
dashboard link: https://syzkaller.appspot.com/bug?extid=f2aaf773187f5cae54f3
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e94728c052e3/disk-80e54e84.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/742f05e27746/vmlinux-80e54e84.xz
kernel image: https://storage.googleapis.com/syzbot-assets/90d418e775f7/bzImage-80e54e84.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f2aaf773187f5cae54f3@syzkaller.appspotmail.com

EXT4-fs (loop0): unmounting filesystem 00000000-0000-0000-0000-000000000000.
==================================================================
BUG: KCSAN: data-race in __filemap_add_folio / invalidate_bdev

read-write to 0xffff888100630570 of 8 bytes by task 3291 on cpu 0:
 __filemap_add_folio+0x430/0x6f0 mm/filemap.c:929
 filemap_add_folio+0x9c/0x1b0 mm/filemap.c:981
 page_cache_ra_unbounded+0x1c1/0x350 mm/readahead.c:276
 do_page_cache_ra mm/readahead.c:328 [inline]
 force_page_cache_ra mm/readahead.c:357 [inline]
 page_cache_sync_ra+0x252/0x680 mm/readahead.c:585
 filemap_get_pages+0x2ca/0x11a0 mm/filemap.c:2580
 filemap_read+0x230/0x8c0 mm/filemap.c:2691
 blkdev_read_iter+0x228/0x2d0 block/fops.c:796
 new_sync_read fs/read_write.c:484 [inline]
 vfs_read+0x5cc/0x6f0 fs/read_write.c:565
 ksys_read+0xe8/0x1b0 fs/read_write.c:708
 __do_sys_read fs/read_write.c:717 [inline]
 __se_sys_read fs/read_write.c:715 [inline]
 __x64_sys_read+0x42/0x50 fs/read_write.c:715
 x64_sys_call+0x2874/0x2dc0 arch/x86/include/generated/asm/syscalls_64.h:1
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff888100630570 of 8 bytes by task 3306 on cpu 1:
 invalidate_bdev+0x25/0x70 block/bdev.c:99
 ext4_put_super+0x571/0x810 fs/ext4/super.c:1356
 generic_shutdown_super+0xe5/0x220 fs/super.c:642
 kill_block_super+0x2a/0x70 fs/super.c:1710
 ext4_kill_sb+0x44/0x80 fs/ext4/super.c:7368
 deactivate_locked_super+0x7d/0x1c0 fs/super.c:473
 deactivate_super+0x9f/0xb0 fs/super.c:506
 cleanup_mnt+0x268/0x2e0 fs/namespace.c:1413
 __cleanup_mnt+0x19/0x20 fs/namespace.c:1420
 task_work_run+0x13a/0x1a0 kernel/task_work.c:227
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:114 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0xa8/0x120 kernel/entry/common.c:218
 do_syscall_64+0xd6/0x1c0 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x000000000000000d -> 0x000000000000000e

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 3306 Comm: syz-executor Not tainted 6.14.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] [fs?] KCSAN: data-race in __filemap_add_folio / invalidate_bdev (8)

[Matthew Wilcox]

On Mon, Mar 10, 2025 at 02:40:26AM -0700, syzbot wrote:
> Reported-by: syzbot+f2aaf773187f5cae54f3@syzkaller.appspotmail.com
> 
> EXT4-fs (loop0): unmounting filesystem 00000000-0000-0000-0000-000000000000.
> ==================================================================
> BUG: KCSAN: data-race in __filemap_add_folio / invalidate_bdev
> 
> read-write to 0xffff888100630570 of 8 bytes by task 3291 on cpu 0:
>  __filemap_add_folio+0x430/0x6f0 mm/filemap.c:929

This is a write to mapping->nrpages with the i_pages lock held, as it
should be.

>  filemap_add_folio+0x9c/0x1b0 mm/filemap.c:981
>  page_cache_ra_unbounded+0x1c1/0x350 mm/readahead.c:276
>  do_page_cache_ra mm/readahead.c:328 [inline]
>  force_page_cache_ra mm/readahead.c:357 [inline]
>  page_cache_sync_ra+0x252/0x680 mm/readahead.c:585
>  filemap_get_pages+0x2ca/0x11a0 mm/filemap.c:2580
>  filemap_read+0x230/0x8c0 mm/filemap.c:2691
>  blkdev_read_iter+0x228/0x2d0 block/fops.c:796
>  new_sync_read fs/read_write.c:484 [inline]
>  vfs_read+0x5cc/0x6f0 fs/read_write.c:565
>  ksys_read+0xe8/0x1b0 fs/read_write.c:708
> 
> read to 0xffff888100630570 of 8 bytes by task 3306 on cpu 1:
>  invalidate_bdev+0x25/0x70 block/bdev.c:99

This is a read of mapping->nrpages with no lock held.  So we could
silence this warning by making this a READ_ONCE or data_race().

The problem is that I'm not sure this is the right answer.  Obviously
here we only care about zero-vs-non-zero, but what if we race with
0 being incremented to 1?  Should there be some locking higher up
that prevents this?  Or is this "yes, root can do this and screw
themselves"?

>  ext4_put_super+0x571/0x810 fs/ext4/super.c:1356
>  generic_shutdown_super+0xe5/0x220 fs/super.c:642
>  kill_block_super+0x2a/0x70 fs/super.c:1710
>  ext4_kill_sb+0x44/0x80 fs/ext4/super.c:7368
>  deactivate_locked_super+0x7d/0x1c0 fs/super.c:473
>  deactivate_super+0x9f/0xb0 fs/super.c:506
>  cleanup_mnt+0x268/0x2e0 fs/namespace.c:1413
>  __cleanup_mnt+0x19/0x20 fs/namespace.c:1420
>  task_work_run+0x13a/0x1a0 kernel/task_work.c:227

[PATCH] block: add lock for safe nrpages access in invalidate_bdev()

[Yuan Tan]

Syzbot reported a data-race in __filemap_add_folio / invalidate_bdev[1]
due to concurrent access to mapping->nrpages.
Adds a lock around the access to nrpages.

[1] https://syzkaller.appspot.com/bug?extid=f2aaf773187f5cae54f3

Signed-off-by: Yuan Tan <tanyuan@tinylab.org>
Reported-by: syzbot+f2aaf773187f5cae54f3@syzkaller.appspotmail.com
---
 block/bdev.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

I had already completed and tested this patch before Matthew sent the
email. I'm not sure if this solution is correct. If it's not, please
ignore the patch :)

diff --git a/block/bdev.c b/block/bdev.c
index 9d73a8fbf7f9..934043d09068 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -96,7 +96,14 @@ void invalidate_bdev(struct block_device *bdev)
 {
 	struct address_space *mapping = bdev->bd_mapping;
 
-	if (mapping->nrpages) {
+	XA_STATE(xas, &mapping->i_pages, 0);  /* we don't care about the index */
+	unsigned long nrpages;
+
+	xas_lock_irq(&xas);
+	nrpages = mapping->nrpages;
+	xas_unlock_irq(&xas);
+
+	if (nrpages) {
 		invalidate_bh_lrus();
 		lru_add_drain_all();	/* make sure all lru add caches are flushed */
 		invalidate_mapping_pages(mapping, 0, -1);
-- 
2.25.1

Re: [PATCH] block: add lock for safe nrpages access in invalidate_bdev()

[Matthew Wilcox]

On Mon, Mar 10, 2025 at 09:54:00AM -0700, Yuan Tan wrote:
> Syzbot reported a data-race in __filemap_add_folio / invalidate_bdev[1]
> due to concurrent access to mapping->nrpages.
> Adds a lock around the access to nrpages.

Did you even read my analysis?  This is a grossly inappropriate fix.
NAK.