Re: Removing ->dirty_folio

[Qu Wenruo <wqu@suse.com>]

在 2026/8/26 04:56, Matthew Wilcox 写道:
> On Tue, Aug 25, 2026 at 08:08:48AM +0930, Qu Wenruo wrote:
>>> The problem is GUP.  We have no way to force the GUP caller to go
>>> through page_mkwrite again.  So instead we make the GUP caller call
>>> folio_mark_dirty_lock() which many just don't, and generally we get away
>>> with it.  But it's a bug, and a bad interface.
>>>
>>> There's also the problem that GUP users bypass the folio_wait_stable()
>>> mechanism.  If a page is written to while somebody is creating a
>>> checksum over that page, the checksum will be corrupted.  If we want
>>> to fix this, we have to bounce-buffer the page.  There's no way to
>>> prevent or delay a GUP user from writing to the page.  Enjoy your RAID.
>>>
>>> My proposal is this:
>>>
>>>    - Fileystems take note of folio_maybe_dma_pinned() during writeback.
>>>      If it's true, do the writeback, but retain/recreate whatever data
>>>      structures you need in order to write the folio again; behave as if
>>>      ->page_mkdirty() had been called again for each page in the folio is
>>>      marked as dirty.
>>
>> This may make COW more complex.
> 
> It's probably wise to be explicit when talking about COW.  Anyone from
> the MM side of the house is probably thinking "but this is only relevant
> for shared writable mmap and we don't do a COW".  You're talking about
> filesystems doing a COW of the on-disc data, not about the MM COWing the
> pagecache page into an anonymous page.
> 
>> For folio_maybe_dma_pinned() case, we will need to do extra space
>> reservation similar to page_mkdirty() again, so that the folio can be
>> written back again.
> 
> Yes, you will.
> 
>> I'm not sure if we will have a good timing for re-reserving space inside
>> btrfs.
> 
> Why is it hard to do it immediately at writeback time?  I think you're
> in an even less restrictive locking environment than page_mkwrite is
> called in because you're not under any MM locks.  According to
> Documentation/filesystems/locking.rst, ->writepages is called with
> absolutely no locks held.

This space reservation problem is a btrfs specific problem.

The root problem here is, btrfs space reservation can trigger 
writeback/transaction commit.

This is due to the data/metadata COW nature, and that's why we rely 
completely on buffered write to do space reservation, and avoid any 
extra space reservation at writeback time.

This is also why we have the complex fixup mechanism, to avoid writing 
the folio that needs fixup, but queue it for space reservation.

Other than other fses to do the space reservation at writeback time.

I believe since we have some space reservation for no-wait writes, it 
can be slightly simplified using no-wait reservation (aka, reserve 
during writeback), but it has a much higher chance to hit ENOSPC.


Although I think on the long run, as long as we want to migrate to 
iomap, we should find out a proper way to address this problem.

> 
>> Would it be possible for MM/VFS layer to trigger page_mkdirty() instead?
> 
> Actually ... no, because the VFS no longer knows which pages in the
> folio are dirty.  That's information the MM had, and communicated to
> the FS which (if it cares) has stored in its folio->private.  But the
> VFS no longer has access to that information.
>