No problematic type usages exist anymore.
Make sure it stays this way.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Nicolas Schier <nsc@kernel.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
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@linutronix.de>
> Reviewed-by: Nicolas Schier <nsc@kernel.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?
Cheers,
Nathan
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@linutronix.de>
> > Reviewed-by: Nicolas Schier <nsc@kernel.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
On Wed, Oct 08, 2025 at 09:52:02PM +0200, Nicolas Schier wrote: > 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. Yeah that seems extremely unlikely to me... Okay, I think I will send Geert's fix for 6.18 then send a patch in a couple of weeks that removes this check from headers_check.pl altogether for 6.19. Cheers, Nathan
Hi Thomas,
On Fri, 15 Aug 2025 at 03:26, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
> No problematic type usages exist anymore.
>
> Make sure it stays this way.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Reviewed-by: Nicolas Schier <nsc@kernel.org>
Thanks for your patch, which is now commit c3a9d74ee413bdb3 ("kbuild:
uapi: upgrade check_sizetypes() warning to error") upstream,
> --- 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;
> }
> }
Unfortunately not all of them have been fixed.
On m68k all{yes,mod}config:
usr/include/asm/bootinfo-amiga.h:18: found __[us]{8,16,32,64} type
without #include <linux/types.h>
make[6]: *** [usr/include/Makefile:89:
usr/include/asm/bootinfo-amiga.hdrtest] Error 1
As this is a false positive, I have sent a fix for headers_check.
"[PATCH] kbuild: uapi: Strip comments before size type check"
https://lore.kernel.org/6e68ab921a728caea4f3f37bfae9b1896edfa97a.1759740354.git.geert@linux-m68k.org
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
© 2016 - 2025 Red Hat, Inc.