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

[Nathan Chancellor <nathan@kernel.org>]

On Wed, Sep 23, 2026 at 01:40:57PM +0300, Jani Nikula wrote:
> On Thu, 17 Sep 2026, Nathan Chancellor <nathan@kernel.org> wrote:
> > 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.
> 
> Do you think the patch at hand is good to go, then? Anything further you
> need from me?

I don't have any other comments or objections. I will give a few days
for other folks to comment on it before I apply it to the kbuild tree.

-- 
Cheers,
Nathan