Re: [PATCH] kbuild: add header check facility as a manually run static analyzer

[Nathan Chancellor]

On Thu, Sep 17, 2026 at 11:05:32AM +0200, Thomas Weißschuh wrote:
> On 2026-09-16 16:13:19-0700, Nathan Chancellor wrote:
> > include/uapi already has its own header checking infrastructure under
> > CONFIG_UAPI_HEADER_TEST and usr/include/Makefile, which avoids this with
> > a no-header-test list that includes many of the files listed in these
> > messages. To be honest, we should probably forbid HEADER_CHECK from
> > including 'include/uapi' and refer people to use CONFIG_UAPI_HEADER_TEST
> > instead, as there are other differences like being built under a
> > different C standard or C++ and such that the existing infrastructure
> > handles.
> 
> Testing the UAPI headers here too would still be valuable.
> CONFIG_UAPI_HEADER_TEST tests the headers from the perspective of
> userspace after they have undergone processing. The kernel build
> might see the same headers quite differently.
> 
> For instance the example from above:
> 
> ./../include/uapi/linux/input.h:29:6: warning: ‘__BITS_PER_LONG’ is not defined, evaluates to ‘0’ [-Wundef]
>    29 | #if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) && !defined(__KERNEL__)
>       |      ^~~~~~~~~~~~~~~
> ./../include/uapi/linux/input.h:34:9: error: unknown type name ‘__kernel_ulong_t’
>    34 |         __kernel_ulong_t __sec;
>       |         ^~~~~~~~~~~~~~~~
> 
> These are legitimate issues, the inclusion of the necessary header is
> gated behind #ifndef __KERNEL__ although it should not be.

Hmmm, fair enough. I guess we can leave this functionality in place for
UAPI headers then but I just worry about people doing what Randy did and
reporting these issues when they are already known and handled in some
other way. Maybe the UAPI header test could grow an "internal kernel
usage" check similar to the other checks that it has at some point then
we could forbid HEADER_CHECK=include/uapi but it is fine for now.

-- 
Cheers,
Nathan