linux-kernel - Re: [PATCH v2 4/5] kbuild: uapi: upgrade check

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

Message-ID: <aObA4vNF4tppZ5vR@levanger>
Date: Wed, 8 Oct 2025 21:52:02 +0200
From: Nicolas Schier <nsc@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] kbuild: uapi: upgrade check_sizetypes() warning
 to error

On Mon, Oct 06, 2025 at 12:00:48PM -0700, Nathan Chancellor wrote:
> On Wed, Aug 13, 2025 at 08:16:59AM +0200, Thomas Weißschuh wrote:
> > No problematic type usages exist anymore.
> > 
> > Make sure it stays this way.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > Reviewed-by: Nicolas Schier <nsc@...nel.org>
> > ---
> >  usr/include/headers_check.pl | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/usr/include/headers_check.pl b/usr/include/headers_check.pl
> > index 36307a137cc1e109e3e1c253f66f3e5935499fc8..36349b21cef5d55241b68ca24dabe6a321b7ce27 100755
> > --- a/usr/include/headers_check.pl
> > +++ b/usr/include/headers_check.pl
> > @@ -159,7 +159,6 @@ sub check_sizetypes
> >  		              "found __[us]{8,16,32,64} type " .
> >  		              "without #include <linux/types.h>\n";
> >  		$linux_types = 2;
> > -		# Warn until headers are all fixed
> > -		#$ret = 1;
> > +		$ret = 1;
> >  	}
> >  }
> > 
> > -- 
> > 2.50.1
> > 
> 
> Geert's regression report and subsequent fix made me look a little
> closer at this check. Is it even useful to do this anymore now that we
> compile test the headers? If these types are found without the
> appropriate include, won't there just be an error? Or is this to avoid
> the case where a system header may transitively include types.h so the
> compile would succeed but the header is not as contained as it could be?

Good question.  I think you're right, that header compiling should be
enough.

I cannot think of a sensible way that with successful header compile
test for an UAPI header file that is not contained. 

Setting USERCFLAGS='-include something/like/types.h' during header
compilation may hide a missing '#include <linux/types.h>', but I don't
think that this is a good reason to keep the checking.

Kind regards,
Nicolas