From: Marco Elver <elver@google.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>, Ingo Molnar <mingo@kernel.org>,
Will Deacon <will@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Chris Li <sparse@chrisli.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Alexander Potapenko <glider@google.com>,
Arnd Bergmann <arnd@arndb.de>, Christoph Hellwig <hch@lst.de>,
Dmitry Vyukov <dvyukov@google.com>,
Eric Dumazet <edumazet@google.com>,
Frederic Weisbecker <frederic@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ian Rogers <irogers@google.com>, Jann Horn <jannh@google.com>,
Joel Fernandes <joelagnelf@nvidia.com>,
Johannes Berg <johannes.berg@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Josh Triplett <josh@joshtriplett.org>,
Justin Stitt <justinstitt@google.com>,
Kees Cook <kees@kernel.org>,
Kentaro Takeda <takedakn@nttdata.co.jp>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Miguel Ojeda <ojeda@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Thomas Gleixner <tglx@linutronix.de>, Thomas Graf <tgraf@suug.ch>,
Uladzislau Rezki <urezki@gmail.com>,
Waiman Long <longman@redhat.com>,
kasan-dev@googlegroups.com, linux-crypto@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org,
linux-sparse@vger.kernel.org, linux-wireless@vger.kernel.org,
llvm@lists.linux.dev, rcu@vger.kernel.org
Subject: Re: [PATCH v5 15/36] srcu: Support Clang's context analysis
Date: Mon, 26 Jan 2026 19:35:33 +0100 [thread overview]
Message-ID: <aXez9fSxdfu5-Boo@elver.google.com> (raw)
In-Reply-To: <dd65bb7b-0dac-437a-a370-38efeb4737ba@acm.org>
On Mon, Jan 26, 2026 at 09:31AM -0800, Bart Van Assche wrote:
> On 12/19/25 7:40 AM, Marco Elver wrote:
> > +/*
> > + * No-op helper to denote that ssp must be held. Because SRCU-protected pointers
> > + * should still be marked with __rcu_guarded, and we do not want to mark them
> > + * with __guarded_by(ssp) as it would complicate annotations for writers, we
> > + * choose the following strategy: srcu_dereference_check() calls this helper
> > + * that checks that the passed ssp is held, and then fake-acquires 'RCU'.
> > + */
> > +static inline void __srcu_read_lock_must_hold(const struct srcu_struct *ssp) __must_hold_shared(ssp) { }
> > /**
> > * srcu_dereference_check - fetch SRCU-protected pointer for later dereferencing
> > @@ -223,9 +233,15 @@ static inline int srcu_read_lock_held(const struct srcu_struct *ssp)
> > * to 1. The @c argument will normally be a logical expression containing
> > * lockdep_is_held() calls.
> > */
> > -#define srcu_dereference_check(p, ssp, c) \
> > - __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > - (c) || srcu_read_lock_held(ssp), __rcu)
> > +#define srcu_dereference_check(p, ssp, c) \
> > +({ \
> > + __srcu_read_lock_must_hold(ssp); \
> > + __acquire_shared_ctx_lock(RCU); \
> > + __auto_type __v = __rcu_dereference_check((p), __UNIQUE_ID(rcu), \
> > + (c) || srcu_read_lock_held(ssp), __rcu); \
> > + __release_shared_ctx_lock(RCU); \
> > + __v; \
> > +})
>
> Hi Marco,
>
> The above change is something I'm not happy about. The original
> implementation of the srcu_dereference_check() macro shows that it is
> sufficient to either hold an SRCU reader lock or the updater lock ('c').
> The addition of "__srcu_read_lock_must_hold()" will cause compilation to
> fail if the caller doesn't hold an SRCU reader lock. I'm concerned that
> this will either lead to adding __no_context_analysis to SRCU updater
> code that uses srcu_dereference_check() or to adding misleading
> __assume_ctx_lock(ssp) annotations in SRCU updater code.
Right, and it doesn't help 'c' is an arbitrary condition. But it's
fundamentally difficult to say "hold either this or that lock".
That being said, I don't think it's wrong to write e.g.:
spin_lock(&updater_lock);
__acquire_shared(ssp);
...
// writes happen through rcu_assign_pointer()
// reads can happen through srcu_dereference_check()
...
__release_shared(ssp);
spin_unlock(&updater_lock);
, given holding the updater lock implies reader access.
And given the analysis is opt-in (CONTEXT_ANALYSIS := y), I think
it's a manageable problem.
If you have a different idea how we can solve this, please let us know.
One final note, usage of srcu_dereference_check() is rare enough:
arch/x86/kvm/hyperv.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
arch/x86/kvm/x86.c: kvm_free_msr_filter(srcu_dereference_check(kvm->arch.msr_filter, &kvm->srcu, 1));
arch/x86/kvm/x86.c: kfree(srcu_dereference_check(kvm->arch.pmu_event_filter, &kvm->srcu, 1));
drivers/gpio/gpiolib.c: label = srcu_dereference_check(desc->label, &desc->gdev->desc_srcu,
drivers/hv/mshv_irq.c: girq_tbl = srcu_dereference_check(partition->pt_girq_tbl,
drivers/hwtracing/stm/core.c: link = srcu_dereference_check(src->link, &stm_source_srcu, 1);
drivers/infiniband/hw/hfi1/user_sdma.c: pq = srcu_dereference_check(fd->pq, &fd->pq_srcu,
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: struct dquot *dquot = srcu_dereference_check(
fs/quota/dquot.c: put[cnt] = srcu_dereference_check(dquots[cnt], &dquot_srcu,
fs/quota/dquot.c: transfer_from[cnt] = srcu_dereference_check(dquots[cnt],
include/linux/kvm_host.h: return srcu_dereference_check(kvm->memslots[as_id], &kvm->srcu,
virt/kvm/irqchip.c: irq_rt = srcu_dereference_check(kvm->irq_routing, &kvm->irq_srcu,
, that I think it's easy enough to annotate these places with the above
suggestions in case you're trying out global enablement.
next prev parent reply other threads:[~2026-01-26 18:35 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 15:39 [PATCH v5 00/36] Compiler-Based Context- and Locking-Analysis Marco Elver
2025-12-19 15:39 ` [PATCH v5 01/36] compiler_types: Move lock checking attributes to compiler-context-analysis.h Marco Elver
2025-12-19 15:39 ` [PATCH v5 02/36] compiler-context-analysis: Add infrastructure for Context Analysis with Clang Marco Elver
2025-12-19 18:38 ` Bart Van Assche
2025-12-19 18:59 ` Marco Elver
2025-12-19 19:04 ` Bart Van Assche
2025-12-19 19:11 ` Marco Elver
2025-12-20 13:33 ` Peter Zijlstra
2025-12-19 15:39 ` [PATCH v5 03/36] compiler-context-analysis: Add test stub Marco Elver
2025-12-19 15:39 ` [PATCH v5 04/36] Documentation: Add documentation for Compiler-Based Context Analysis Marco Elver
2025-12-19 18:51 ` Bart Van Assche
2025-12-19 15:39 ` [PATCH v5 05/36] checkpatch: Warn about context_unsafe() without comment Marco Elver
2025-12-19 15:39 ` [PATCH v5 06/36] cleanup: Basic compatibility with context analysis Marco Elver
2025-12-19 19:16 ` Bart Van Assche
2026-01-06 13:21 ` Tetsuo Handa
2026-01-06 17:34 ` Marco Elver
2026-01-27 10:14 ` Lorenzo Stoakes
2026-01-27 10:17 ` Marco Elver
2026-01-27 10:21 ` Lorenzo Stoakes
2025-12-19 15:39 ` [PATCH v5 07/36] lockdep: Annotate lockdep assertions for " Marco Elver
2025-12-19 20:53 ` Bart Van Assche
2025-12-19 21:16 ` Marco Elver
2025-12-19 21:28 ` Bart Van Assche
2025-12-19 21:47 ` Marco Elver
2025-12-19 15:39 ` [PATCH v5 08/36] locking/rwlock, spinlock: Support Clang's " Marco Elver
2025-12-19 20:26 ` Bart Van Assche
2025-12-19 21:02 ` Marco Elver
2025-12-19 21:34 ` Bart Van Assche
2025-12-19 21:48 ` Marco Elver
2025-12-19 21:45 ` Bart Van Assche
2025-12-19 15:39 ` [PATCH v5 09/36] compiler-context-analysis: Change __cond_acquires to take return value Marco Elver
2025-12-19 15:39 ` [PATCH v5 10/36] locking/mutex: Support Clang's context analysis Marco Elver
2026-01-08 22:10 ` Bart Van Assche
2026-01-08 23:26 ` Marco Elver
2026-01-09 6:02 ` Christoph Hellwig
2026-01-09 13:07 ` Steven Rostedt
2026-01-10 3:23 ` Marco Elver
2025-12-19 15:40 ` [PATCH v5 11/36] locking/seqlock: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 12/36] bit_spinlock: Include missing <asm/processor.h> Marco Elver
2025-12-19 20:38 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 13/36] bit_spinlock: Support Clang's context analysis Marco Elver
2025-12-19 20:47 ` Bart Van Assche
2025-12-19 21:09 ` Marco Elver
2025-12-19 15:40 ` [PATCH v5 14/36] rcu: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 15/36] srcu: " Marco Elver
2026-01-26 17:31 ` Bart Van Assche
2026-01-26 18:35 ` Marco Elver [this message]
2026-01-26 18:54 ` Bart Van Assche
2026-01-26 21:35 ` Peter Zijlstra
2026-01-26 23:46 ` Marco Elver
2025-12-19 15:40 ` [PATCH v5 16/36] kref: Add context-analysis annotations Marco Elver
2025-12-19 20:49 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 17/36] locking/rwsem: Support Clang's context analysis Marco Elver
2025-12-19 20:55 ` Bart Van Assche
2025-12-20 12:52 ` Marco Elver
2025-12-19 15:40 ` [PATCH v5 18/36] locking/local_lock: Include missing headers Marco Elver
2025-12-19 20:56 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 19/36] locking/local_lock: Support Clang's context analysis Marco Elver
2025-12-19 15:40 ` [PATCH v5 20/36] locking/ww_mutex: " Marco Elver
2026-01-09 20:16 ` Bart Van Assche
2026-01-09 21:06 ` Marco Elver
2026-01-09 21:26 ` Bart Van Assche
2026-01-12 10:32 ` Maarten Lankhorst
2025-12-19 15:40 ` [PATCH v5 21/36] debugfs: Make debugfs_cancellation a context lock struct Marco Elver
2025-12-19 21:01 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 22/36] um: Fix incorrect __acquires/__releases annotations Marco Elver
2025-12-19 21:05 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 23/36] compiler-context-analysis: Remove Sparse support Marco Elver
2025-12-19 21:38 ` Bart Van Assche
2025-12-19 15:40 ` [PATCH v5 24/36] compiler-context-analysis: Remove __cond_lock() function-like helper Marco Elver
2025-12-19 21:42 ` Bart Van Assche
2025-12-20 12:51 ` Marco Elver
2025-12-19 15:40 ` [PATCH v5 25/36] compiler-context-analysis: Introduce header suppressions Marco Elver
2025-12-19 15:40 ` [PATCH v5 26/36] compiler: Let data_race() imply disabled context analysis Marco Elver
2025-12-19 15:40 ` [PATCH v5 27/36] MAINTAINERS: Add entry for Context Analysis Marco Elver
2025-12-19 15:40 ` [PATCH v5 28/36] kfence: Enable context analysis Marco Elver
2025-12-19 15:40 ` [PATCH v5 29/36] kcov: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 30/36] kcsan: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 31/36] stackdepot: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 32/36] rhashtable: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 33/36] printk: Move locking annotation to printk.c Marco Elver
2025-12-19 15:40 ` [PATCH v5 34/36] security/tomoyo: Enable context analysis Marco Elver
2025-12-19 15:40 ` [PATCH v5 35/36] crypto: " Marco Elver
2025-12-19 15:40 ` [PATCH v5 36/36] sched: Enable context analysis for core.c and fair.c Marco Elver
2026-01-12 22:04 ` Bart Van Assche
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=aXez9fSxdfu5-Boo@elver.google.com \
--to=elver@google.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dvyukov@google.com \
--cc=edumazet@google.com \
--cc=frederic@kernel.org \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=irogers@google.com \
--cc=jannh@google.com \
--cc=joelagnelf@nvidia.com \
--cc=johannes.berg@intel.com \
--cc=josh@joshtriplett.org \
--cc=justinstitt@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kees@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=lukas.bulwahn@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=nathan@kernel.org \
--cc=neeraj.upadhyay@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=sparse@chrisli.org \
--cc=takedakn@nttdata.co.jp \
--cc=tglx@linutronix.de \
--cc=tgraf@suug.ch \
--cc=urezki@gmail.com \
--cc=will@kernel.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