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 12:40:31 +0200
| Newsgroups | org.kernel.vger.linux-btrfs,org.kernel.vger.kvm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-s390,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
Am 22.07.26 um 11:35 schrieb Qu Wenruo: > > > 在 2026/7/22 18:59, Christian Borntraeger 写道: >> Am 22.07.26 um 10:59 schrieb Qu Wenruo: >>> >>> >>> 在 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. >> So I now have an userspace O_DIRECT reproducer outside of KVM. (attached) which gave me (on an s390 system, though) > > Thanks a lot, I can also reproduce it on arm64 (64K page size). > > This is super bad, as we have just removed a lot of folio ordered related code to detect such problem. > > I'll also check if it's some recent btrfs changes making it worse. The RFC patch from yesterday seems to fix _THIS_ problem, but as you outlined, there might be other issues that break and are not handled by my patch.