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