Re: [PATCH/RFC] btrfs: fix folio lock leak in writepage_delalloc() for folios dirtied behind btrfs' back

在 2026/7/22 18:05, Christian Borntraeger 写道:
> Am 21.07.26 um 23:07 schrieb Qu Wenruo:
> 
> First, thank you for taking the time to look into this and trying to 
> understand
> things and trying to explain things. this is highly appreciated.
> I am still trying to fully understand this myself. A question:
> 
>> 在 2026/7/22 04:41, Christian Borntraeger 写道:
>>> A folio can carry the folio-level dirty flag while its btrfs subpage
>>> dirty bitmap is empty: btrfs data mappings use filemap_dirty_folio(),
>>> so a generic folio_mark_dirty() call sets only the folio flag and the
>>> xarray tag, without setting any subpage dirty bit and without a
>>> delalloc reservation.  The typical source is set_page_dirty_lock() on
>>> a GUP pin,
>>
>> Shouldn't such folio got its ->page_mkwrite() callback get called first?
> 
> Isnt that called implicitely at pin time?

I have to admit, I'm not an expert on the MM part, I'm mostly a simple 
user of the existing MM interfaces.

AFAIK, the last time I brought this thing up, Christoph mentioned that 
dirtying-folio-without-notifying-fs is a bug, and fs should not and is 
not able to handle such situation anyway.

And that idea makes a lot of sense to me.

So adding MM list for more help.

Thanks,
Qu

> At unpin, set_page_dirty_lock() re-dirties the now-clean folio.
>  From what I can see, this is not an s390 invention but a sanctioned 
> pattern.
> 
> But I can certainly not exclude that this is still an s390 specific 
> problem.
> Let me dig a bit deeper.
> 
> Thanks again for your quick response.
> 
> Christian
>