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 01/12] rcu_txn: Add single-writer RCU pseudo-transactions
Date: Fri, 23 Oct 2026 11:22:10 -0700 [thread overview]
Message-ID: <20261023182218.479327-1-puranjay@kernel.org> (raw)
In-Reply-To: <20261016133319.433617-2-mathieu.desnoyers@efficios.com>
On Fri, Oct 16, 2026 at 09:33:08AM -0400, Mathieu Desnoyers wrote:
[...]
> The records and the selector live in one descriptor, allocated with the
> gfp_t given to rcu_txn_init() and freed with kfree_rcu() after a commit
> that installed proxies. A descriptor that installed none, after a
> commit of one record or a cancel, owes no grace period: it is freed with
> kfree() or, on PREEMPT_RT, with kfree_rcu(): rcu_txn_commit() and
> rcu_txn_cancel() may then be called under a raw or a bit spinlock on
> every kernel, as a hash table with hlist_bl buckets does. An allocation
This isn't quite true on !PREEMPT_RT. As far as lockdep is concerned,
kfree() can't be called under a raw_spinlock_t on any kernel: once the
per-CPU sheaf is full, SLUB takes barn->lock, a spinlock_t, and
PROVE_RAW_LOCK_NESTING flags that whether or not PREEMPT_RT is set.
kfree_rcu() gets away with it because mm/slub.c annotates its sheaf
path for exactly this case (kfree_rcu_sheaf_map); kfree() has no such
annotation.
[...]
> +/*
> + * Free a descriptor that installed no proxy, which owes no grace period.
> + * commit() and cancel() may run under a raw or a bit spinlock, where
> + * PREEMPT_RT does not allow kfree(). It does allow kfree_rcu().
> + */
> +void __rcu_txn_free_desc(struct rcu_txn_desc *desc)
> +{
> + if (IS_ENABLED(CONFIG_PREEMPT_RT))
> + kfree_rcu(desc, rcu_head);
> + else
> + kfree(desc);
A single commit rarely trips it, since barn->lock is only taken once the
sheaf is full, and lockdep skips the wait-context check for the fast
path's trylock. 4096 reserved one-record commits under one raw spinlock
do trip it. This is the series as posted, on arm64 with
PROVE_LOCKING and PROVE_RAW_LOCK_NESTING:
[ BUG: Invalid wait context ]
kunit_try_catch/44 is trying to lock:
ffff000001804318 (&barn->lock){....}-{3:3}, at: __pcs_replace_full_main+0x4b4/0x514
locks held by kunit_try_catch/44: 2, last CPU#1:
#0: ffff80008080c120 (exp_raw_lock){....}-{2:2}, at: exp_bulk+0x1cc/0x2fc
#1: ffff00003fda37a0 ((local_lock_t *)&pcs->lock){+.+.}-{3:3}, at: local_trylock_acquire+0x14/0x8c
[...]
Call trace:
_raw_spin_lock_irqsave+0x60/0x88
__pcs_replace_full_main+0x4b4/0x514
kfree+0x400/0x43c
__rcu_txn_free_desc+0x10/0x1c
rcu_txn_commit+0x54/0x11c
exp_bulk+0x250/0x2fc
rcu_txn_test_exp_bulk_commit_raw+0x14/0x20
Cancels give the same splat, and so does a loop doing one commit per
raw-lock section once the sheaf fills up.
Using kfree_rcu() unconditionally fixes it, and the rest of the suite
still passes (against the top of the series):
--- a/lib/rcu_txn.c
+++ b/lib/rcu_txn.c
@@ -73,9 +73,6 @@ static struct rcu_txn_desc *rcu_txn_desc_alloc(unsigned int cap, gfp_t gfp)
*/
void __rcu_txn_free_desc(struct rcu_txn_desc *desc)
{
- if (IS_ENABLED(CONFIG_PREEMPT_RT))
- kfree_rcu(desc, rcu_head);
- else
- kfree(desc);
+ kfree_rcu(desc, rcu_head);
}
EXPORT_SYMBOL_GPL(__rcu_txn_free_desc);
The cost is a grace period of delay before freeing descriptors that
never installed a proxy. I'd take that over a wait-type override
around the !PREEMPT_RT kfree(), since it also removes the RT/!RT split.
This makes a few comments stale: the kerneldoc of rcu_txn_cancel(),
the comment above __rcu_txn_free_desc(), the two "no proxy: free now"
comments, the comment above rcu_txn_test_single_record() in patch 2
and the one above rcu_txn_test_commit_atomic() in patch 10, plus the
commit messages of patches 1 and 10. On the other hand, the "Readers
and reclaim" comment, which says commit reclaims with kfree_rcu(), and
the raw spinlock paragraph in rcu_txn.rst only become true with it.
Thanks,
Puranjay
next prev parent reply other threads:[~2026-10-23 18:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 13:33 [RFC PATCH 00/12] " 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 [this message]
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
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=20261023182218.479327-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®