From: Puranjay Mohan <puranjay@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
linux-kernel@vger.kernel.org, Boqun Feng <boqun@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joelagnelf@nvidia.com>,
Uladzislau Rezki <urezki@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang@linux.dev>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Christian Brauner <brauner@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Liam R . Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
Andrew Ballance <andrewjballance@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Ingo Molnar <mingo@kernel.org>, Thomas Gleixner <tglx@kernel.org>,
rcu@vger.kernel.org
Subject: Re: [RFC PATCH 00/12] RCU pseudo-transactions
Date: Fri, 23 Oct 2026 11:19:39 -0700 [thread overview]
Message-ID: <20261023181940.457424-1-puranjay@kernel.org> (raw)
In-Reply-To: <20261016133319.433617-1-mathieu.desnoyers@efficios.com>
Hi Mathieu,
On Fri, Oct 16, 2026 at 09:33:07AM -0400, Mathieu Desnoyers wrote:
> I'd specifically like feedback on:
>
> - Where this should live (kernel/rcu/, lib/?),
>
> - Naming and API shape (descriptor + records),
>
> - Whether the Bloom filter threshold should be a config knob,
>
> - Subsystems where this could apply.
I went through the series and ran the KUnit suite on arm64 (QEMU/KVM)
with PROVE_LOCKING, PROVE_RAW_LOCK_NESTING and DEBUG_RCU_TXN. All 59
cases pass, and herd7 agrees with all 21 litmus tests. The
install/flip/settle ordering and the descriptor lifetime look right to
me.
I found two bugs, details in the replies to the patches:
- patch 1: a one-record commit or a cancel frees the descriptor with
kfree() on !PREEMPT_RT, which lockdep can flag as an invalid wait
context under a raw spinlock;
- patch 3: rcu_txn_load() on a consumed handle with an armed Bloom
filter dereferences a NULL descriptor.
Moves in patch 6 can also make a reader skip or revisit nodes, or loop
in another list instead of terminating if the node moves there. In
patch 5, deleting a node twice can silently corrupt the bucket.
On your questions:
Location: either works for me, but CONFIG_RCU_TXN is in lib/Kconfig and
CONFIG_DEBUG_RCU_TXN in kernel/rcu/Kconfig.debug; I'd keep them
together.
Naming: no strong opinion.
Bloom filter knob: I wouldn't add one. Outside the KUnit tests, the
only transactions that reach eight records are the mutex sample's
evicting insertions, which reserve 32 records anyway. Meanwhile the
room reserved for the filter pushes descriptors of 8 to 10 records from
512 to 1024 bytes. I'd drop patch 3 until something needs it.
API shape: every rcu_txn_list add, delete and replace allocates a
descriptor and frees it with kfree_rcu(), so all of them can fail with
-ENOMEM, delete included. That is hard to use on teardown paths, and
reserving first only moves the failure. Since a descriptor can be
reused a grace period after its commit, have you considered a small
cache of them, tagged with start_poll_synchronize_rcu() and checked with
poll_state_synchronize_rcu()? Separately, a one-record transaction
never installs a proxy but still allocates a descriptor, 256 bytes
unless reserved smaller; keeping the first record inline in struct
rcu_txn would avoid that.
Subsystems: in dcache the hash buckets are hlist_bl, with bit 0 of the
head as the lock, and d_unhashed() tests for a NULL pprev.
rcu_txn_hlist hard-codes bit 0 as its tag and has no unhashed state, so
I'm curious how your userspace port deals with both. Also, the only
in-tree user of list_bidir_prev_rcu(), kernel/nstree.c, walks either way
but never forward and then back in one walk, so a user that needs that
guarantee would help make the case for patch 6.
I can send my KUnit reproducers as patches if they're useful.
Thanks,
Puranjay
prev parent reply other threads:[~2026-10-23 18:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 13:33 Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 01/12] rcu_txn: Add single-writer " Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 02/12] rcu_txn: Add KUnit tests Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 03/12] rcu_txn: Skip the record lookup with a Bloom filter Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 04/12] rcu_txn: Add CONFIG_DEBUG_RCU_TXN Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 05/12] rcu_txn: Add an hlist edited through transactions Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 06/12] rcu_txn: Add a doubly-linked list coherent in both directions Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 07/12] Documentation/RCU: Describe RCU pseudo-transactions Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 08/12] Documentation/litmus-tests: Add RCU pseudo-transaction tests Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 09/12] rcu_txn: Test a list writer against concurrent readers Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 10/12] rcu_txn: Test a commit from atomic context Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-16 13:33 ` [RFC PATCH 11/12] samples: Add a cache on RCU pseudo-transactions under one mutex Mathieu Desnoyers
2026-10-16 13:33 ` [RFC PATCH 12/12] samples: Add a cache on RCU pseudo-transactions with a lock per node Mathieu Desnoyers
2026-10-23 18:22 ` Puranjay Mohan
2026-10-19 0:55 ` [RFC PATCH 00/12] RCU pseudo-transactions Joel Fernandes
2026-10-23 13:37 ` Mathieu Desnoyers
2026-10-23 18:19 ` Puranjay Mohan [this message]
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=20261023181940.457424-1-puranjay@kernel.org \
--to=puranjay@kernel.org \
--cc=aliceryhl@google.com \
--cc=andrewjballance@gmail.com \
--cc=boqun@kernel.org \
--cc=brauner@kernel.org \
--cc=frederic@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jiangshanlai@gmail.com \
--cc=joelagnelf@nvidia.com \
--cc=josh@joshtriplett.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang@linux.dev \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/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
all inboxes | Powered by JetHome®