On Thu, 2025-03-27 at 14:42 -0700, Luis Chamberlain wrote: > On Thu, Mar 27, 2025 at 09:26:41AM -0700, syzbot wrote: > > Hello, > > Thanks, this is a known issue and we're having a hard time > reproducing [0]. > > > C reproducer: > > https://syzkaller.appspot.com/x/repro.c?x=152d4de4580000 > > Thanks! Sadly this has not yet been able to let me reprodouce the > issue, > and so we're trying to come up with other ways to test the imminent > spin > lock + sleep on buffer_migrate_folio_norefs() path different ways > now, > including a new fstests [1] but no luck yet. The backtrace in the report seems to make the cause of the bug fairly clear, though. The function folio_mc_copy() can sleep. The function __buffer_migrate_folio() calls filemap_migrate_folio() with a spinlock held. That function eventually calls folio_mc_copy(): __might_resched+0x5d4/0x780 kernel/sched/core.c:8764 folio_mc_copy+0x13c/0x1d0 mm/util.c:742 __migrate_folio mm/migrate.c:758 [inline] filemap_migrate_folio+0xb4/0x4c0 mm/migrate.c:943 __buffer_migrate_folio+0x3ec/0x5d0 mm/migrate.c:874 move_to_new_folio+0x2ac/0xc20 mm/migrate.c:1050 migrate_folio_move mm/migrate.c:1358 [inline] migrate_folios_move mm/migrate.c:1710 [inline] The big question is how to safely release the spinlock in __buffer_migrate_folio() before calling filemap_migrate_folio() -- All Rights Reversed.
