linux-kernel - Re: [RFC PATCH] btrfs: defer freeing of subpage private state to free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee4898be-b0e0-4163-b734-c2891239dce6@gmx.com>
Date: Sat, 31 Jan 2026 07:06:59 +1030
From: Qu Wenruo <quwenruo.btrfs@....com>
To: JP Kobryn <inwardvessel@...il.com>, Matthew Wilcox <willy@...radead.org>
Cc: boris@....io, clm@...com, dsterba@...e.com, linux-btrfs@...r.kernel.org,
 linux-kernel@...r.kernel.org, kernel-team@...a.com,
 "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC PATCH] btrfs: defer freeing of subpage private state to
 free_folio



在 2026/1/31 03:40, JP Kobryn 写道:
> On 1/29/26 9:14 PM, Matthew Wilcox wrote:
>> On Fri, Jan 30, 2026 at 01:46:59PM +1030, Qu Wenruo wrote:
>>> Another question is, why only two fses (nfs for dir inode, and 
>>> orangefs) are
>>> utilizing the free_folio() callback.
>>
>> Alas, secretmem and guest_memfd are also using it.  Nevertheless, I'm
>> not a fan of this interface existing, and would prefer to not introduce
>> new users.  Like launder_folio, which btrfs has also mistakenly used.
>>
> 
> The part that felt concerning is how the private state is lost. If
> release_folio() frees this state but the folio persists in the cache,
> users of the folio afterward have to recreate the state. Is that the
> expectation on how filesystems should handle this situation?

I believe that's the case.

Just like what we did in btrfs_do_readpage() and prepare_one_folio().

There is no difference between getting a new page and a page that is 
released but not removed from the filemap.

> 
> In the case of the existing btrfs code, when the state is recreated (in
> subpage mode), the bitmap data and lock states are all zeroed.

That's expected.

Thanks,
Qu