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: <aUWWn3YMOrPdyY_c@gourry-fedora-PF4VCD3F>
Date: Fri, 19 Dec 2025 13:17:03 -0500
From: Gregory Price <gourry@...rry.net>
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
> (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.
>

Such a fundamental change needs additional validation to show there's no
obvious failures.  Have you run this through a model checker to verify
the only failure condition is the 2^31 overflow condition you describe?

A single benchmark and a short changelog is leaves me very uneasy about
such a change.

~Gregory