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 05/12] rcu_txn: Add an hlist edited through transactions
Date: Fri, 23 Oct 2026 11:22:13 -0700 [thread overview]
Message-ID: <20261023182218.479327-4-puranjay@kernel.org> (raw)
In-Reply-To: <20261016133319.433617-6-mathieu.desnoyers@efficios.com>
On Fri, Oct 16, 2026 at 09:33:12AM -0400, Mathieu Desnoyers wrote:
[...]
> + * - Every node an operation is anchored on must still be in the list as the
> + * transaction leaves it. A single-writer delete leaves no deletion mark:
> + * nothing in a deleted anchor distinguishes it from a live one.
[...]
> +static inline void rcu_txn_hlist_del_rcu(struct rcu_txn_hlist_node *elem)
> +{
> + struct rcu_txn_hlist_node __rcu **ppv = __rcu_txn_hlist_pprev(elem);
> + struct rcu_txn_hlist_node *next = __rcu_txn_hlist_load(&elem->next);
> +
> + rcu_assign_pointer(*ppv, next);
> + if (next)
> + RCU_INIT_POINTER(next->pprev, ppv);
> +}
hlist_del_rcu() poisons pprev, so a double delete faults straight away.
Here pprev keeps pointing at the old slot, so a second del_rcu() quietly
overwrites whatever that slot holds now with the node's stale ->next.
For example, 1 -> 2 -> 3, del_rcu(2), add_behind_rcu(4, 1), del_rcu(2)
leaves 1 -> 3 with node 4 gone, and nothing warns, even with
CONFIG_DEBUG_RCU_TXN. Had 3 been deleted and freed in between, the
second delete would link it back in and write to it.
dcache relies on d_unhashed(), i.e. a NULL pprev, which __d_drop() sets.
Could the _rcu delete and replace clear pprev the way
hlist_del_init_rcu() does, and could there be an
rcu_txn_hlist_unhashed()? For the _prepare forms, del_prepare and
replace_prepare could record pprev -> NULL through
__rcu_txn_hlist_record_pprev(). That costs at most one record, though a
lone delete or replace of a bucket's last node would no longer be a
one-record commit.
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] RCU pseudo-transactions 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 [this message]
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-4-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®