linux-kernel - Re: [PATCH v5 15/36] srcu: Support Clang's context analysis

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8c1bbab4-4615-4518-b773-a006d1402b8b@acm.org>
Date: Mon, 26 Jan 2026 10:54:56 -0800
From: Bart Van Assche <bvanassche@....org>
To: Marco Elver <elver@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Boqun Feng <boqun.feng@...il.com>,
 Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
 "David S. Miller" <davem@...emloft.net>,
 Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
 Chris Li <sparse@...isli.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Alexander Potapenko <glider@...gle.com>, Arnd Bergmann <arnd@...db.de>,
 Christoph Hellwig <hch@....de>, Dmitry Vyukov <dvyukov@...gle.com>,
 Eric Dumazet <edumazet@...gle.com>, Frederic Weisbecker
 <frederic@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Herbert Xu <herbert@...dor.apana.org.au>, Ian Rogers <irogers@...gle.com>,
 Jann Horn <jannh@...gle.com>, Joel Fernandes <joelagnelf@...dia.com>,
 Johannes Berg <johannes.berg@...el.com>, Jonathan Corbet <corbet@....net>,
 Josh Triplett <josh@...htriplett.org>, Justin Stitt
 <justinstitt@...gle.com>, Kees Cook <kees@...nel.org>,
 Kentaro Takeda <takedakn@...data.co.jp>,
 Lukas Bulwahn <lukas.bulwahn@...il.com>, Mark Rutland
 <mark.rutland@....com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Miguel Ojeda <ojeda@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
 Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
 Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
 Steven Rostedt <rostedt@...dmis.org>,
 Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
 Thomas Gleixner <tglx@...utronix.de>, Thomas Graf <tgraf@...g.ch>,
 Uladzislau Rezki <urezki@...il.com>, Waiman Long <longman@...hat.com>,
 kasan-dev@...glegroups.com, linux-crypto@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org,
 linux-security-module@...r.kernel.org, linux-sparse@...r.kernel.org,
 linux-wireless@...r.kernel.org, llvm@...ts.linux.dev, rcu@...r.kernel.org
Subject: Re: [PATCH v5 15/36] srcu: Support Clang's context analysis

On 1/26/26 10:35 AM, Marco Elver wrote:
> 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.

I'd like to make context-analysis mandatory for the entire kernel tree.

> 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.

Has it ever been considered to add support in the clang compiler for a
variant of __must_hold() that expresses that one of two capabilities
must be held by the caller? I think that would remove the need to
annotate SRCU update-side code with __acquire_shared(ssp) and
__release_shared(ssp).

Thanks,

Bart.