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: <1ac1c25f-9f4a-45ea-8ce5-c4a381941d60@infradead.org>
Date: Fri, 23 Jan 2026 16:37:01 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Peter Zijlstra <peterz@...radead.org>,
 Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: 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 1/23/26 7:18 AM, Peter Zijlstra wrote:
> 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()

I was aware of some of these but not all of them.
Thanks for the list.
I'll update my patch for one regex to include all of these.

-- 
~Randy