Re: [syzbot] [btrfs?] kernel BUG in __folio_start_writeback

[Qu Wenruo]

在 2024/11/25 07:56, Matthew Wilcox 写道:
> On Sun, Nov 24, 2024 at 05:45:18AM -0800, syzbot wrote:
> >   __fput+0x5ba/0xa50 fs/file_table.c:458
> >   task_work_run+0x24f/0x310 kernel/task_work.c:239
> >   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+0x13f/0x340 kernel/entry/common.c:218
> >   do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
> >   entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> This is:
>
>          VM_BUG_ON_FOLIO(folio_test_writeback(folio), folio);
>
> ie we've called __folio_start_writeback() on a folio which is already
> under writeback.
>
> Higher up in the trace, we have the useful information:
>
>   page: refcount:6 mapcount:0 mapping:ffff888077139710 index:0x3 pfn:0x72ae5
>   memcg:ffff888140adc000
>   aops:btrfs_aops ino:105 dentry name(?):"file2"
>   flags: 0xfff000000040ab(locked|waiters|uptodate|lru|private|writeback|node=0|zone=1|lastcpupid=0x7ff)
>   raw: 00fff000000040ab ffffea0001c8f408 ffffea0000939708 ffff888077139710
>   raw: 0000000000000003 0000000000000001 00000006ffffffff ffff888140adc000
>   page dumped because: VM_BUG_ON_FOLIO(folio_test_writeback(folio))
>   page_owner tracks the page as allocated
>
> The interesting part of the page_owner stacktrace is:
>
>    filemap_alloc_folio_noprof+0xdf/0x500
>    __filemap_get_folio+0x446/0xbd0
>    prepare_one_folio+0xb6/0xa20
>    btrfs_buffered_write+0x6bd/0x1150
>    btrfs_direct_write+0x52d/0xa30
>    btrfs_do_write_iter+0x2a0/0x760
>    do_iter_readv_writev+0x600/0x880
>    vfs_writev+0x376/0xba0
>
> (ie not very interesting)
>
> > Workqueue: btrfs-delalloc btrfs_work_helper
> > RIP: 0010:__folio_start_writeback+0xc06/0x1050 mm/page-writeback.c:3119
> > Call Trace:
> >   <TASK>
> >   process_one_folio fs/btrfs/extent_io.c:187 [inline]
> >   __process_folios_contig+0x31c/0x540 fs/btrfs/extent_io.c:216
> >   submit_one_async_extent fs/btrfs/inode.c:1229 [inline]
> >   submit_compressed_extents+0xdb3/0x16e0 fs/btrfs/inode.c:1632
> >   run_ordered_work fs/btrfs/async-thread.c:245 [inline]
> >   btrfs_work_helper+0x56b/0xc50 fs/btrfs/async-thread.c:324
> >   process_one_work kernel/workqueue.c:3229 [inline]
>
> This looks like a race?
>
> process_one_folio() calls
> btrfs_folio_clamp_set_writeback calls
> btrfs_subpage_set_writeback:
>
>          spin_lock_irqsave(&subpage->lock, flags);
>          bitmap_set(subpage->bitmaps, start_bit, len >> fs_info->sectorsize_bits)
> ;
>          if (!folio_test_writeback(folio))
>                  folio_start_writeback(folio);
>          spin_unlock_irqrestore(&subpage->lock, flags);
>
> so somebody else set writeback after we tested for writeback here.

The test VM is using X86_64, thus we won't go into the subpage routine, 
but directly call folio_start_writeback().

> One thing that comes to mind is that _usually_ we take folio_lock()
> first, then start writeback, then call folio_unlock() and btrfs isn't
> doing that here (afaict).  Maybe that's not the source of the bug?

We still hold the folio locked, do submission then unlock.

You can check extent_writepage(), where at the entrance we check if the 
folio is still locked.
Then inside extent_writepage_io() we do the submission, setting the 
folio writeback inside submit_one_sector().
Eventually unlock the folio at the end of extent_writepage(), that's for 
the uncompressed writes.

There are a lot of special handling for async submission (compression), 
but it  still holds the folio locked, do compression and submission, and 
unlock, just all in another thread (this case).

So it looks like something is wrong when transferring the ownership of 
the page cache folios to the compression path, or some not properly 
handled error path.

Unfortunately I'm not really able to reproduce the case using the 
reproducer...

Thanks,
Qu



> If it is, should we have a VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio)
> in __folio_start_writeback()?  Or is there somewhere that can't lock the
> folio before starting writeback?