Re: [RFC] mm/migrate: make sure folio_unlock() before folio_wait_writeback()

David Hildenbrand
2025-10-02T11:39:06Z

> To simplify the scenario:
>

Just curious, where is the __folio_start_writeback() to complete the
picture?

> context X (wq worker) context Y (process context)
>
> migrate_pages_batch()
> ext4_end_io_end() ...
> ... migrate_folio_unmap()
> ext4_get_inode_loc() ...
> ... folio_lock() // hold the folio lock
> bdev_getblk() ...
> ... folio_wait_writeback() // wait forever
> __find_get_block_slow()
> ... ...
> folio_lock() // wait forever
> folio_unlock() migrate_folio_undo_src()
> ...
> ... folio_unlock() // never reachable
> ext4_finish_bio()
> ...
> folio_end_writeback() // never reachable
>

But aren't you implying that it should from this point on be disallowed
to call folio_wait_writeback() with the folio lock held? That sounds ...
a bit wrong.

Note that it is currently explicitly allowed: folio_wait_writeback()
documents "If the folio is not locked, writeback may start again after
writeback has finished.". So there is no way to prevent writeback from
immediately starting again.

In particular, wouldn't we have to fixup other callsites to make this
consistent and then VM_WARN_ON_ONCE() assert that in folio_wait_writeback()?

Of course, as we've never seen this deadlock before in practice, I do
wonder if something else prevents it?

If it's a real issue, I wonder if a trylock on the writeback path could
be an option.

--
Cheers

David / dhildenb