All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Marco Elver <elver@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Documentation <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: linux-next: [DOCS] build warning after merge of the tip tree
Date: Fri, 23 Jan 2026 13:20:54 +0100	[thread overview]
Message-ID: <20260123132054.2d46fb97@foz.lan> (raw)
In-Reply-To: <20260123112856.GS166857@noisy.programming.kicks-ass.net>

Hi Peter,

On Fri, 23 Jan 2026 12:28:56 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Jan 23, 2026 at 08:11:26AM +0100, Mauro Carvalho Chehab wrote:
> 
> > >  tools/lib/python/kdoc/kdoc_parser.py |    1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > --- a/tools/lib/python/kdoc/kdoc_parser.py
> > > +++ b/tools/lib/python/kdoc/kdoc_parser.py
> > > @@ -186,6 +186,7 @@ function_xforms  = [
> > >      (KernRe(r"__sched +"), ""),
> > >      (KernRe(r"_noprof"), ""),
> > >      (KernRe(r"__always_unused *"), ""),
> > > +    (KernRe(r"__cond_acquires\s*\(.*\)"), ""),  
> > 
> > Regex here is too broad, as it is greedy: it may drop more
> > than expected. Perhaps:
> > 
> >     (KernRe(r"__cond_acquires\s*\([^\)]*\)"), ""),  
> 
> 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.

> 
> 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 is a variant for very complex macros - currently used
    only for struct_group_*.

Thanks,
Mauro

  reply	other threads:[~2026-01-23 12:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07  5:15 linux-next: build warning after merge of the tip tree Stephen Rothwell
2026-01-07 21:54 ` Peter Zijlstra
2026-01-07 22:10   ` Randy Dunlap
2026-01-23  1:06     ` linux-next: [DOCS] " Randy Dunlap
2026-01-23  7:11       ` Mauro Carvalho Chehab
2026-01-23  7:17         ` Randy Dunlap
2026-01-23 11:28         ` Peter Zijlstra
2026-01-23 12:20           ` Mauro Carvalho Chehab [this message]
2026-01-23 15:18             ` Peter Zijlstra
2026-01-24  0:37               ` Randy Dunlap

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=20260123132054.2d46fb97@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=corbet@lwn.net \
    --cc=elver@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.