linux-kernel - Re: [RFC PATCH 2/2] mm: implement page refcount locking via dedicated bit

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: <9822c658-c2f0-4b1c-9eef-9ffa865e44f7@h-partners.com>
Date: Fri, 19 Dec 2025 19:18:53 +0300
From: Gladyshev Ilya <gladyshev.ilya1@...artners.com>
To: Kiryl Shutsemau <kirill@...temov.name>
CC: <guohanjun@...wei.com>, <wangkefeng.wang@...wei.com>,
	<weiyongjun1@...wei.com>, <yusongping@...wei.com>, <leijitang@...wei.com>,
	<artem.kuzin@...wei.com>, <stepanov.anatoly@...wei.com>,
	<alexander.grubnikov@...wei.com>, <gorbunov.ivan@...artners.com>,
	<akpm@...ux-foundation.org>, <david@...nel.org>,
	<lorenzo.stoakes@...cle.com>, <Liam.Howlett@...cle.com>, <vbabka@...e.cz>,
	<rppt@...nel.org>, <surenb@...gle.com>, <mhocko@...e.com>, <ziy@...dia.com>,
	<harry.yoo@...cle.com>, <willy@...radead.org>, <yuzhao@...gle.com>,
	<baolin.wang@...ux.alibaba.com>, <muchun.song@...ux.dev>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/2] mm: implement page refcount locking via dedicated
 bit

On 12/19/2025 5:50 PM, Kiryl Shutsemau wrote:
> On Fri, Dec 19, 2025 at 12:46:39PM +0000, Gladyshev Ilya wrote:
>> The current atomic-based page refcount implementation treats zero
>> counter as dead and requires a compare-and-swap loop in folio_try_get()
>> to prevent incrementing a dead refcount. This CAS loop acts as a
>> serialization point and can become a significant bottleneck during
>> high-frequency file read operations.
>>
>> This patch introduces FOLIO_LOCKED_BIT to distinguish between a
> 
> s/FOLIO_LOCKED_BIT/PAGEREF_LOCKED_BIT/
Ack, thanks

>> (temporary) zero refcount and a locked (dead/frozen) state. Because now
>> incrementing counter doesn't affect it's locked/unlocked state, it is
>> possible to use an optimistic atomic_fetch_add() in
>> page_ref_add_unless_zero() that operates independently of the locked bit.
>> The locked state is handled after the increment attempt, eliminating the
>> need for the CAS loop.
> 
> I don't think I follow.
> 
> Your trick with the PAGEREF_LOCKED_BIT helps with serialization against
> page_ref_freeze(), but I don't think it does anything to serialize
> against freeing the page under you.
> 
> Like, if the page in the process of freeing, page allocator sets its
> refcount to zero and your version of page_ref_add_unless_zero()
> successfully acquirees reference for the freed page.
> 
> How is it safe?

Page is freed only after a successful page_ref_dec_and_test() call, 
which will set LOCKED_BIT. This bit will persist until set_page_count(1) 
is called somewhere in the allocation path [alloc_pages()], and 
effectively block any "use after free" users.