linux-kernel - Re: [PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none

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]

Date:   Wed, 29 Nov 2017 16:35:03 +0000
From:   Will Deacon <will.deacon@....com>
To:     Jonathan Corbet <corbet@....net>
Cc:     linux-kernel@...r.kernel.org, mawilcox@...rosoft.com
Subject: Re: [PATCH 1/3] scripts/kernel-doc: Don't fail with status != 0 if
 error encountered with -none

On Wed, Nov 29, 2017 at 09:12:14AM -0700, Jonathan Corbet wrote:
> On Wed, 29 Nov 2017 15:20:03 +0000
> Will Deacon <will.deacon@....com> wrote:
> 
> > My bisect scripts starting running into build failures when trying to
> > compile 4.15-rc1 with the builds failing with things like:
> > 
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
> > 
> > The line in question is actually just a #define, but after some digging
> > it turns out that my scripts pass W=1 and since commit 3a025e1d1c2ea
> > ("Add optional check for bad kernel-doc comments") that results in
> > kernel-doc running on each source file. The file in question has a
> > badly formatted comment immediately before the #define:
> > 
> > /**
> >  * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
> >  * bus layer usage.
> >  */
> > 
> > which causes the regex in dump_struct to fail (lack of braces following
> > struct declaration) and kernel-doc returns 1, which causes the build
> > to fail.
> > 
> > Fix the issue by always returning 0 from kernel-doc when invoked with
> > -none. It successfully generates no documentation, and prints out any
> > issues.
> 
> That seems like a worthy fix.  I can take this one and ship it up with a
> few other docs fixes in the near future, thanks.

Brill, cheers Jon. It had me extremely confused for a while until I figured
out the warning wasn't coming from GCC :)

Will