From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Peter Zijlstra <peterz@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 08:11:26 +0100 [thread overview]
Message-ID: <20260123081126.3f0f152c@foz.lan> (raw)
In-Reply-To: <91c5386a-2c1b-476a-b189-86d80c0d9e96@infradead.org>
On Thu, 22 Jan 2026 17:06:28 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:
> + linux-doc + Jon
>
> On 1/7/26 2:10 PM, Randy Dunlap wrote:
> >
> >
> > On 1/7/26 1:54 PM, Peter Zijlstra wrote:
> >> On Wed, Jan 07, 2026 at 04:15:48PM +1100, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> After merging the tip tree, today's linux-next build (htmldocs) produced
> >>> this warning:
> >>>
> >>> Documentation/core-api/kref:328: include/linux/kref.h:72: WARNING: Invalid C declaration: Expected end of definition. [error at 96]
> >>> int kref_put_mutex (struct kref *kref, void (*release)(struct kref *kref), str
> >>> uct mutex *mutex) __cond_acquires(true# mutex)
> >>> ------------------------------------------------------------------------------------------------^
> >>> Documentation/core-api/kref:328: include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
> >>> int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
> >>> --------------------------------------------------------------------------------------------^
> >>>
> >>> Introduced by commit
> >>>
> >>> 5e256db9325e ("kref: Add context-analysis annotations")
> >>
> >> I really have no clue what that thing is on about. The code is fine and
> >> works as intended.
> >>
> >> My go-to fix for anything kdoc is to change '/**' into '/*' until it
> >> goes away.
> >
> > Yes, that works.
> >
> > I think that kernel-doc is just confused by the trailing __cond_acquires(true# lock).
> >
> > Mauro, would you take a look, please?
> We can trivially ignore "__cond_acquires(.*)" in kernel-doc to
> eliminate such build warnings.
>
> Is that sufficient? Sure.
> Is it the right thing to do? IDK.
> Comments?
This fix sounds right to me. If not there at the patch,
I would improve the include/linux/kref.h documentation to
describe __cond_requires() inside the kernel-doc documentation
(or at kref.rst).
>
> ~Randy
> ---
> 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*\([^\)]*\)"), ""),
With that, feel free to add:
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> (KernRe(r"__printf\s*\(\s*\d*\s*,\s*\d*\s*\) +"), ""),
> (KernRe(r"__(?:re)?alloc_size\s*\(\s*\d+\s*(?:,\s*\d+\s*)?\) +"), ""),
> (KernRe(r"__diagnose_as\s*\(\s*\S+\s*(?:,\s*\d+\s*)*\) +"), ""),
>
Thanks,
Mauro
next prev parent reply other threads:[~2026-01-23 7:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260107161548.45530e1c@canb.auug.org.au>
[not found] ` <20260107215409.GB694817@noisy.programming.kicks-ass.net>
[not found] ` <803d1946-6935-452d-953a-90f6e73d53a2@infradead.org>
2026-01-23 1:06 ` linux-next: [DOCS] build warning after merge of the tip tree Randy Dunlap
2026-01-23 7:11 ` Mauro Carvalho Chehab [this message]
2026-01-23 7:17 ` Randy Dunlap
2026-01-23 11:28 ` Peter Zijlstra
2026-01-23 12:20 ` Mauro Carvalho Chehab
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=20260123081126.3f0f152c@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox