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

[Jani Nikula <jani.nikula@intel.com>]

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?

BR,
Jani.


-- 
Jani Nikula, Intel