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

Christian Borntraeger <[email protected]> Wed, 22 Jul 2026 10:35:25 +0200
Newsgroups org.kernel.vger.linux-btrfs,org.kernel.vger.kvm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390
Message-ID <[email protected]>
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?
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