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: <iv7m5rmuwssltl6yzwuop3ry5s4l653lykyvrmmy6qdbyyuoew@th5xuev3mwus>
Date: Fri, 19 Dec 2025 14:50:17 +0000
From: Kiryl Shutsemau <kirill@...temov.name>
To: Gladyshev Ilya <gladyshev.ilya1@...artners.com>
Cc: patchwork@...wei.com, 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 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/

> (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?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov