linux-kernel - Re: linux-next: [DOCS] build warning after merge of the tip tree

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] [day] [month] [year] [list]

Message-ID: <20260123151856.GT166857@noisy.programming.kicks-ass.net>
Date: Fri, 23 Jan 2026 16:18:56 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: Randy Dunlap <rdunlap@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Marco Elver <elver@...gle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Linux Documentation <linux-doc@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>
Subject: Re: linux-next: [DOCS] build warning after merge of the tip tree

On Fri, Jan 23, 2026 at 01:20:54PM +0100, Mauro Carvalho Chehab wrote:

> > I have of course no idea what so ever how any of this works, but it
> > occurs to me that __acquires() and __releases() are not in that same
> > list, what happens to them?
> 
> You mean in functions like those, for instance:
> 
> 	int device_links_read_lock(void) __acquires(&device_links_srcu)
> 	{
> 	        return srcu_read_lock(&device_links_srcu);
> 	}
> 
> 	void device_links_read_unlock(int idx) __releases(&device_links_srcu)
> 	{
> 	        srcu_read_unlock(&device_links_srcu, idx);
> 	}
> 
> Yeah, we need to add something for those as well.

Yes those. They are pre-existing sparse annotations that have been
co-opted and morphed into the clang thread-safety-analysis.

> > Also, there will 'soon' be an equivalent: __cond_releases():
> > 
> >   https://lkml.kernel.org/r/20260121111213.634625032@infradead.org
> 
> The table "function_xforms" is a set of regular expressions to replace 
> macros into something that will be a pure C function declaration.
> It should be able to handle most macros (*).
> 
> Each line in the table has two arguments:
> 
> 	- a regex
> 	- a replace expression
> 
> In this specific case, if we remove __cond_acquires(.*) from the
> function prototype, the remaining function will be a pure C 
> prototype.
> 
> So, I'd say we need to have all 4 macros there:
> 
> 	(KernRe(r"__cond_acquires\s*\([^\)]*\)"), ""),
> 	(KernRe(r"__cond_releases\s*\([^\)]*\)"), ""),
> 	(KernRe(r"__acquires\s*\([^\)]*\)"), ""),
> 	(KernRe(r"__releases\s*\([^\)]*\)"), ""),
> 
> to avoid any warnings related to such annotations.

There's also:

	__must_hold()
	__must_not_hold()
	__must_hold_shared()

	__acquires_shared()
	__cond_acquires_shared()
	__releases_shared()

	__no_context_analysis

On top of that, structure members can be annotated with:

	__guarded_by()
	__pt_guarded_by()


Thanks!