From: Kiryl Shutsemau <kirill@shutemov.name>
To: Gladyshev Ilya <gladyshev.ilya1@h-partners.com>
Cc: guohanjun@huawei.com, wangkefeng.wang@huawei.com,
weiyongjun1@huawei.com, yusongping@huawei.com,
leijitang@huawei.com, artem.kuzin@huawei.com,
stepanov.anatoly@huawei.com, alexander.grubnikov@huawei.com,
gorbunov.ivan@h-partners.com, akpm@linux-foundation.org,
david@kernel.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ziy@nvidia.com,
harry.yoo@oracle.com, willy@infradead.org, yuzhao@google.com,
baolin.wang@linux.alibaba.com, muchun.song@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] mm: implement page refcount locking via dedicated bit
Date: Fri, 19 Dec 2025 17:46:40 +0000 [thread overview]
Message-ID: <ans3mrfqd6jv5hfarbx5bzsl2ugtatbfyjw2vlv5ybuhevjc4i@46f45fdds5m7> (raw)
In-Reply-To: <9822c658-c2f0-4b1c-9eef-9ffa865e44f7@h-partners.com>
On Fri, Dec 19, 2025 at 07:18:53PM +0300, Gladyshev Ilya wrote:
> 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.
Okay, fair enough.
But what prevent the following scenario?
CPU0 CPU1
page_ref_dec_and_test()
atomic_dec_and_test() // refcount=0
page_ref_add_unless_zero()
atomic_add_return() // refcount=1, no LOCKED_BIT
page_ref_dec_and_test()
atomic_dec_and_test() // refcount=0
atomic_cmpxchg(0, LOCKED_BIT) // succeeds
atomic_cmpxchg(0, LOCKED_BIT) // fails
// return false to caller
// Use-after-free: BOOM!
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2025-12-19 17:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 12:46 [RFC PATCH 0/2] mm: improve folio refcount scalability Gladyshev Ilya
2025-12-19 12:46 ` [RFC PATCH 1/2] mm: make ref_unless functions unless_zero only Gladyshev Ilya
2025-12-19 12:46 ` [RFC PATCH 2/2] mm: implement page refcount locking via dedicated bit Gladyshev Ilya
2025-12-19 14:50 ` Kiryl Shutsemau
2025-12-19 16:18 ` Gladyshev Ilya
2025-12-19 17:46 ` Kiryl Shutsemau [this message]
2025-12-19 19:08 ` Gladyshev Ilya
2025-12-22 13:33 ` Kiryl Shutsemau
2025-12-19 18:17 ` Gregory Price
2025-12-22 12:42 ` Gladyshev Ilya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ans3mrfqd6jv5hfarbx5bzsl2ugtatbfyjw2vlv5ybuhevjc4i@46f45fdds5m7 \
--to=kirill@shutemov.name \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.grubnikov@huawei.com \
--cc=artem.kuzin@huawei.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=gladyshev.ilya1@h-partners.com \
--cc=gorbunov.ivan@h-partners.com \
--cc=guohanjun@huawei.com \
--cc=harry.yoo@oracle.com \
--cc=leijitang@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=rppt@kernel.org \
--cc=stepanov.anatoly@huawei.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=weiyongjun1@huawei.com \
--cc=willy@infradead.org \
--cc=yusongping@huawei.com \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox