[PATCH 0/4] vDSO: Use 32-bit CHECKFLAGS for compat vDSO

[PATCH 0/4] vDSO: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Weißschuh]

When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
are used. These are combined with the 32-bit CFLAGS. This confuses
sparse, producing false-positive warnings or potentially missing
real issues.

Manually override the CHECKFLAGS for the compat vDSO with the correct
32-bit configuration.

Not all architectures are supported, as many do not use sparse for their
(compat) vDSO. These can be enabled later.

Also add some checks to bitsperlong.h to detect such issues earlier.

Based on tip/timers/vdso.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Thomas Weißschuh (4):
      sparc64: vdso: Use 32-bit CHECKFLAGS for compat vDSO
      x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO
      s390/vdso: Trim includes in linker script
      asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

 arch/s390/kernel/vdso/vdso.lds.S       |  3 +--
 arch/sparc/vdso/Makefile               |  3 +++
 arch/x86/entry/vdso/Makefile           |  3 +++
 include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
 4 files changed, 21 insertions(+), 2 deletions(-)
---
base-commit: a37abd052c0bd9d1194710a39008801379f8ff5a
change-id: 20251107-vdso-compat-checkflags-5db75b3b4bac

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH 1/4] sparc64: vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Weißschuh]

When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
are used. These are combined with the 32-bit CFLAGS. This confuses
sparse, producing false-positive warnings or potentially missing
real issues.

Manually override the CHECKFLAGS for the compat vDSO with the correct
32-bit configuration.

Reported-by: From: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/lkml/202511030021.9v1mIgts-lkp@intel.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

---
The actual false-positive is only reported when SPARC is converted over
to the generic vDSO library. However the issue is already present.
To avoid dependencies between different patch queues, I have this patch
in this one.
---
 arch/sparc/vdso/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
index 13f1d7be00f1..945d917b0058 100644
--- a/arch/sparc/vdso/Makefile
+++ b/arch/sparc/vdso/Makefile
@@ -90,6 +90,9 @@ KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
 KBUILD_CFLAGS_32 += -mv8plus
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
+CHECKFLAGS_32 := $(CHECKFLAGS) -U__sparc_v9__ -U__arch64__ -m32
+$(obj)/vdso32.so.dbg: CHECKFLAGS = $(CHECKFLAGS_32)
+
 $(obj)/vdso32.so.dbg: FORCE \
 			$(obj)/vdso32/vdso32.lds \
 			$(obj)/vdso32/vclock_gettime.o \

-- 
2.52.0

Re: [PATCH 1/4] sparc64: vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Arnd Bergmann]

On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
> are used. These are combined with the 32-bit CFLAGS. This confuses
> sparse, producing false-positive warnings or potentially missing
> real issues.
>
> Manually override the CHECKFLAGS for the compat vDSO with the correct
> 32-bit configuration.
>
> Reported-by: From: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/lkml/202511030021.9v1mIgts-lkp@intel.com/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Weißschuh]

When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
are used. These are combined with the 32-bit CFLAGS. This confuses
sparse, producing false-positive warnings or potentially missing
real issues.

Manually override the CHECKFLAGS for the compat vDSO with the correct
32-bit configuration.

Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
Closes: https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/x86/entry/vdso/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index f247f5f5cb44..ab571ad9b9ac 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -142,7 +142,10 @@ ifneq ($(RETPOLINE_VDSO_CFLAGS),)
 endif
 endif
 
+CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32
+
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
+$(obj)/vdso32.so.dbg: CHECKFLAGS = $(CHECKFLAGS_32)
 
 $(obj)/vdso32.so.dbg: $(obj)/vdso32/vdso32.lds $(vobjs32) FORCE
 	$(call if_changed,vdso_and_check)

-- 
2.52.0

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Arnd Bergmann]

On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
> are used. These are combined with the 32-bit CFLAGS. This confuses
> sparse, producing false-positive warnings or potentially missing
> real issues.
>
> Manually override the CHECKFLAGS for the compat vDSO with the correct
> 32-bit configuration.
>
> Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
> Closes: 
> https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

> +CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32
> +
>  $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
> +$(obj)/vdso32.so.dbg: CHECKFLAGS = $(CHECKFLAGS_32)

Have you checked if something like this is needed for x32 as well?

     Arnd

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Weißschuh]

On Fri, Jan 16, 2026 at 08:49:12AM +0100, Arnd Bergmann wrote:
> On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> > When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
> > are used. These are combined with the 32-bit CFLAGS. This confuses
> > sparse, producing false-positive warnings or potentially missing
> > real issues.
> >
> > Manually override the CHECKFLAGS for the compat vDSO with the correct
> > 32-bit configuration.
> >
> > Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
> > Closes: 
> > https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> > +CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32
> > +
> >  $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
> > +$(obj)/vdso32.so.dbg: CHECKFLAGS = $(CHECKFLAGS_32)
> 
> Have you checked if something like this is needed for x32 as well?

It didn't show up in my testing. I think this is explained by the x32 vDSO
being built as 64-bit and only converted to x32 afterwards.

Thomas

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[H. Peter Anvin]

On January 16, 2026 12:09:34 AM PST, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
>On Fri, Jan 16, 2026 at 08:49:12AM +0100, Arnd Bergmann wrote:
>> On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
>> > When building the compat vDSO the CHECKFLAGS from the 64-bit kernel
>> > are used. These are combined with the 32-bit CFLAGS. This confuses
>> > sparse, producing false-positive warnings or potentially missing
>> > real issues.
>> >
>> > Manually override the CHECKFLAGS for the compat vDSO with the correct
>> > 32-bit configuration.
>> >
>> > Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
>> > Closes: 
>> > https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
>> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>> 
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> 
>> > +CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32
>> > +
>> >  $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
>> > +$(obj)/vdso32.so.dbg: CHECKFLAGS = $(CHECKFLAGS_32)
>> 
>> Have you checked if something like this is needed for x32 as well?
>
>It didn't show up in my testing. I think this is explained by the x32 vDSO
>being built as 64-bit and only converted to x32 afterwards.
>
>Thomas

This is going to crash hard with the changes in tip:x86/entry.

But yes, the x32 vdso is currently really just a wrapped version on the 64-bit code, and as long as there are no pointers to pointers used in the vdso ABI there isn't really a reason to change that.

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Gleixner]

On Fri, Jan 16 2026 at 08:40, Thomas Weißschuh wrote:
> Manually override the CHECKFLAGS for the compat vDSO with the correct
> 32-bit configuration.

Fun. I just fixed the same thing half an hour ago:

   https://lore.kernel.org/lkml/20260117215542.342638347@kernel.org/

> Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
> Closes: https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  arch/x86/entry/vdso/Makefile | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index f247f5f5cb44..ab571ad9b9ac 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -142,7 +142,10 @@ ifneq ($(RETPOLINE_VDSO_CFLAGS),)
>  endif
>  endif
>  
> +CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32

Hmm. That keeps -m64. Seems not to matter much, but substituting both
seems to be more correct.

Thanks,

        tglx

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[Thomas Weißschuh]

On Sat, Jan 17, 2026 at 11:05:05PM +0100, Thomas Gleixner wrote:
> On Fri, Jan 16 2026 at 08:40, Thomas Weißschuh wrote:
> > Manually override the CHECKFLAGS for the compat vDSO with the correct
> > 32-bit configuration.
> 
> Fun. I just fixed the same thing half an hour ago:
> 
>    https://lore.kernel.org/lkml/20260117215542.342638347@kernel.org/

Assuming you are going to apply your patches bevore, can I respin my
remaining patches on top of tip/x86/entry?

> > Reported-by: Sun Jian <sun.jian.kdev@gmail.com>
> > Closes: https://lore.kernel.org/lkml/20260114084529.1676356-1-sun.jian.kdev@gmail.com/
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  arch/x86/entry/vdso/Makefile | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> > index f247f5f5cb44..ab571ad9b9ac 100644
> > --- a/arch/x86/entry/vdso/Makefile
> > +++ b/arch/x86/entry/vdso/Makefile
> > @@ -142,7 +142,10 @@ ifneq ($(RETPOLINE_VDSO_CFLAGS),)
> >  endif
> >  endif
> >  
> > +CHECKFLAGS_32 := $(CHECKFLAGS) -U__x86_64__ -D__i386__ -m32
> 
> Hmm. That keeps -m64. Seems not to matter much, but substituting both
> seems to be more correct.

Fair enough.


Thomas

Re: [PATCH 2/4] x86/vdso: Use 32-bit CHECKFLAGS for compat vDSO

[H. Peter Anvin]

On 2026-01-18 23:20, Thomas Weißschuh wrote:
> On Sat, Jan 17, 2026 at 11:05:05PM +0100, Thomas Gleixner wrote:
>> On Fri, Jan 16 2026 at 08:40, Thomas Weißschuh wrote:
>>> Manually override the CHECKFLAGS for the compat vDSO with the correct
>>> 32-bit configuration.
>>
>> Fun. I just fixed the same thing half an hour ago:
>>
>>    https://lore.kernel.org/lkml/20260117215542.342638347@kernel.org/
> 
> Assuming you are going to apply your patches bevore, can I respin my
> remaining patches on top of tip/x86/entry?
> 

Please do.

	-hpa

[PATCH 3/4] s390/vdso: Trim includes in linker script

[Thomas Weißschuh]

Some of the included files are unnecessary or too broad.

This is a preparation for a new validation step to validate the
consistency of __BITS_PER_LONG. vdso.lds.S may be preprocessed with a
32-bit compiler, but __BITS_PER_LONG is always 64.

Trim the includes to the necessary ones.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

---
There are other ways to solve this issue, for example using
KBUILD_CPPFLAGS += -m64.
---
 arch/s390/kernel/vdso/vdso.lds.S | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/s390/kernel/vdso/vdso.lds.S b/arch/s390/kernel/vdso/vdso.lds.S
index 7bec4de0e8e0..c8abd00799be 100644
--- a/arch/s390/kernel/vdso/vdso.lds.S
+++ b/arch/s390/kernel/vdso/vdso.lds.S
@@ -4,11 +4,10 @@
  * library
  */
 
-#include <asm/vdso/vsyscall.h>
-#include <asm/page.h>
 #include <asm/vdso.h>
 #include <asm-generic/vmlinux.lds.h>
 #include <vdso/datapage.h>
+#include <vdso/page.h>
 
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
 OUTPUT_ARCH(s390:64-bit)

-- 
2.52.0

Re: [PATCH 3/4] s390/vdso: Trim includes in linker script

[Arnd Bergmann]

On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> Some of the included files are unnecessary or too broad.
>
> This is a preparation for a new validation step to validate the
> consistency of __BITS_PER_LONG. vdso.lds.S may be preprocessed with a
> 32-bit compiler, but __BITS_PER_LONG is always 64.
>
> Trim the includes to the necessary ones.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

It's certainly a good idea to limit the use of asm/page.h and the
other headers here. 

> There are other ways to solve this issue, for example using
> KBUILD_CPPFLAGS += -m64.

I think we should probably do that as well, especially since my
kernel.org cross-compilers still default to a 32-bit s390 target
for historic reasons, but the kernel no longer supports 32-bit
userland.

    Arnd

Re: [PATCH 3/4] s390/vdso: Trim includes in linker script

[Thomas Weißschuh]

On Fri, Jan 16, 2026 at 08:45:02AM +0100, Arnd Bergmann wrote:
> On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> > Some of the included files are unnecessary or too broad.
> >
> > This is a preparation for a new validation step to validate the
> > consistency of __BITS_PER_LONG. vdso.lds.S may be preprocessed with a
> > 32-bit compiler, but __BITS_PER_LONG is always 64.
> >
> > Trim the includes to the necessary ones.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> It's certainly a good idea to limit the use of asm/page.h and the
> other headers here. 
> 
> > There are other ways to solve this issue, for example using
> > KBUILD_CPPFLAGS += -m64.
> 
> I think we should probably do that as well, especially since my
> kernel.org cross-compilers still default to a 32-bit s390 target
> for historic reasons, but the kernel no longer supports 32-bit
> userland.

Agreed. However I'd like to keep this series as small as possible.
The same change should also be done to a bunch of other architectures.


Thomas

Re: [PATCH 3/4] s390/vdso: Trim includes in linker script

[Heiko Carstens]

On Fri, Jan 16, 2026 at 08:40:26AM +0100, Thomas Weißschuh wrote:
> Some of the included files are unnecessary or too broad.
> 
> This is a preparation for a new validation step to validate the
> consistency of __BITS_PER_LONG. vdso.lds.S may be preprocessed with a
> 32-bit compiler, but __BITS_PER_LONG is always 64.
> 
> Trim the includes to the necessary ones.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  arch/s390/kernel/vdso/vdso.lds.S | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Acked-by: Heiko Carstens <hca@linux.ibm.com>

[PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

The value of __BITS_PER_LONG from architecture-specific logic should
always match the generic one if that is available. It should also match
the actual C type 'long'.

Mismatches can happen for example when building the compat vDSO. Either
during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
when mismatched CHECKFLAGS are inherited from the kernel build.

Add some consistency checks which detect such issues early and clearly.
The tests are added to the UAPI header to make sure it is also used when
building the vDSO as that is not supposed to use regular kernel headers.

The kernel-interal BITS_PER_LONG is not checked as it is derived from
CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
deactivated check in include/asm-generic/bitsperlong.h.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
index fadb3f857f28..9d762097ae0c 100644
--- a/include/uapi/asm-generic/bitsperlong.h
+++ b/include/uapi/asm-generic/bitsperlong.h
@@ -28,4 +28,18 @@
 #define __BITS_PER_LONG_LONG 64
 #endif
 
+/* Consistency checks */
+#ifdef __KERNEL__
+#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
+#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
+#error Inconsistent word size. Check uapi/asm/bitsperlong.h
+#endif
+#endif
+
+#ifndef __ASSEMBLER__
+_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
+	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
+#endif
+#endif /* __KERNEL__ */
+
 #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */

-- 
2.52.0

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Arnd Bergmann]

On Fri, Jan 16, 2026, at 08:40, Thomas Weißschuh wrote:
> The value of __BITS_PER_LONG from architecture-specific logic should
> always match the generic one if that is available. It should also match
> the actual C type 'long'.
>
> Mismatches can happen for example when building the compat vDSO. Either
> during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> when mismatched CHECKFLAGS are inherited from the kernel build.
>
> Add some consistency checks which detect such issues early and clearly.
> The tests are added to the UAPI header to make sure it is also used when
> building the vDSO as that is not supposed to use regular kernel headers.
>
> The kernel-interal BITS_PER_LONG is not checked as it is derived from
> CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> deactivated check in include/asm-generic/bitsperlong.h.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[David Laight]

On Fri, 16 Jan 2026 08:40:27 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:

> The value of __BITS_PER_LONG from architecture-specific logic should
> always match the generic one if that is available. It should also match
> the actual C type 'long'.
> 
> Mismatches can happen for example when building the compat vDSO. Either
> during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> when mismatched CHECKFLAGS are inherited from the kernel build.
> 
> Add some consistency checks which detect such issues early and clearly.
> The tests are added to the UAPI header to make sure it is also used when
> building the vDSO as that is not supposed to use regular kernel headers.
> 
> The kernel-interal BITS_PER_LONG is not checked as it is derived from
> CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> deactivated check in include/asm-generic/bitsperlong.h.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> index fadb3f857f28..9d762097ae0c 100644
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -28,4 +28,18 @@
>  #define __BITS_PER_LONG_LONG 64
>  #endif
>  
> +/* Consistency checks */
> +#ifdef __KERNEL__
> +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> +#endif
> +#endif
> +
> +#ifndef __ASSEMBLER__
> +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");

nak...

You can't assume the compiler has _Static_assert().
All the ones that do probably define __SIZEOF_LONG__.
You could use something 'old-school' like:
typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];

	David

> +#endif
> +#endif /* __KERNEL__ */
> +
>  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> 

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> On Fri, 16 Jan 2026 08:40:27 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> 
> > The value of __BITS_PER_LONG from architecture-specific logic should
> > always match the generic one if that is available. It should also match
> > the actual C type 'long'.
> > 
> > Mismatches can happen for example when building the compat vDSO. Either
> > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > when mismatched CHECKFLAGS are inherited from the kernel build.
> > 
> > Add some consistency checks which detect such issues early and clearly.
> > The tests are added to the UAPI header to make sure it is also used when
> > building the vDSO as that is not supposed to use regular kernel headers.
> > 
> > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > deactivated check in include/asm-generic/bitsperlong.h.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > index fadb3f857f28..9d762097ae0c 100644
> > --- a/include/uapi/asm-generic/bitsperlong.h
> > +++ b/include/uapi/asm-generic/bitsperlong.h
> > @@ -28,4 +28,18 @@
> >  #define __BITS_PER_LONG_LONG 64
> >  #endif
> >  
> > +/* Consistency checks */
> > +#ifdef __KERNEL__
> > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > +#endif
> > +#endif
> > +
> > +#ifndef __ASSEMBLER__
> > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> 
> nak...
> 
> You can't assume the compiler has _Static_assert().
> All the ones that do probably define __SIZEOF_LONG__.
> You could use something 'old-school' like:
> typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];

This is only used when building the kernel, it never actually reaches
userspace. And all supported compilers for the kernel do have _Static_assert().
As indicated by other users of _Static_assert() we have elsewhere in the tree.

> 
> 	David
> 
> > +#endif
> > +#endif /* __KERNEL__ */
> > +
> >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[David Laight]

On Mon, 19 Jan 2026 11:13:08 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:

> On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> > On Fri, 16 Jan 2026 08:40:27 +0100
> > Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> >   
> > > The value of __BITS_PER_LONG from architecture-specific logic should
> > > always match the generic one if that is available. It should also match
> > > the actual C type 'long'.
> > > 
> > > Mismatches can happen for example when building the compat vDSO. Either
> > > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > > when mismatched CHECKFLAGS are inherited from the kernel build.
> > > 
> > > Add some consistency checks which detect such issues early and clearly.
> > > The tests are added to the UAPI header to make sure it is also used when
> > > building the vDSO as that is not supposed to use regular kernel headers.
> > > 
> > > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > > deactivated check in include/asm-generic/bitsperlong.h.
> > > 
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > ---
> > >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> > >  1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > > index fadb3f857f28..9d762097ae0c 100644
> > > --- a/include/uapi/asm-generic/bitsperlong.h
> > > +++ b/include/uapi/asm-generic/bitsperlong.h
> > > @@ -28,4 +28,18 @@
> > >  #define __BITS_PER_LONG_LONG 64
> > >  #endif
> > >  
> > > +/* Consistency checks */
> > > +#ifdef __KERNEL__
> > > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > > +#endif
> > > +#endif
> > > +
> > > +#ifndef __ASSEMBLER__
> > > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");  
> > 
> > nak...
> > 
> > You can't assume the compiler has _Static_assert().
> > All the ones that do probably define __SIZEOF_LONG__.
> > You could use something 'old-school' like:
> > typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];  
> 
> This is only used when building the kernel, it never actually reaches
> userspace. And all supported compilers for the kernel do have _Static_assert().
> As indicated by other users of _Static_assert() we have elsewhere in the tree.

Don't you need a check that it isn't wrong on a user system?
Which is what I thought it was doing.

The earlier check can also just be:

#if defined(__SIZEOF_LONG__) && __BITS_PER_LONG != 8 * __SIZEOF_LONG__
#error Inconsistent word size. Check uapi/asm/bitsperlong.h
#endif

	David

> 
> > 
> > 	David
> >   
> > > +#endif
> > > +#endif /* __KERNEL__ */
> > > +
> > >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */  

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:
> On Mon, 19 Jan 2026 11:13:08 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> 
> > On Mon, Jan 19, 2026 at 10:06:19AM +0000, David Laight wrote:
> > > On Fri, 16 Jan 2026 08:40:27 +0100
> > > Thomas Weißschuh <thomas.weissschuh@linutronix.de> wrote:
> > >   
> > > > The value of __BITS_PER_LONG from architecture-specific logic should
> > > > always match the generic one if that is available. It should also match
> > > > the actual C type 'long'.
> > > > 
> > > > Mismatches can happen for example when building the compat vDSO. Either
> > > > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > > > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > > > when mismatched CHECKFLAGS are inherited from the kernel build.
> > > > 
> > > > Add some consistency checks which detect such issues early and clearly.
> > > > The tests are added to the UAPI header to make sure it is also used when
> > > > building the vDSO as that is not supposed to use regular kernel headers.
> > > > 
> > > > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > > > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > > > deactivated check in include/asm-generic/bitsperlong.h.
> > > > 
> > > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > > ---
> > > >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > > > index fadb3f857f28..9d762097ae0c 100644
> > > > --- a/include/uapi/asm-generic/bitsperlong.h
> > > > +++ b/include/uapi/asm-generic/bitsperlong.h
> > > > @@ -28,4 +28,18 @@
> > > >  #define __BITS_PER_LONG_LONG 64
> > > >  #endif
> > > >  
> > > > +/* Consistency checks */
> > > > +#ifdef __KERNEL__
> > > > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > > > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > > > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > > > +#endif
> > > > +#endif
> > > > +
> > > > +#ifndef __ASSEMBLER__
> > > > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > > > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");  
> > > 
> > > nak...
> > > 
> > > You can't assume the compiler has _Static_assert().
> > > All the ones that do probably define __SIZEOF_LONG__.
> > > You could use something 'old-school' like:
> > > typedef char __inconsistent_long_size[1 - 2 * (sizeof(long) * 8 != __BITS_PER_LONG))];  
> > 
> > This is only used when building the kernel, it never actually reaches
> > userspace. And all supported compilers for the kernel do have _Static_assert().
> > As indicated by other users of _Static_assert() we have elsewhere in the tree.
> 
> Don't you need a check that it isn't wrong on a user system?
> Which is what I thought it was doing.

Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
being tested here. If they work in the kernel build I assume they also work
in userspace.

> The earlier check can also just be:
> 
> #if defined(__SIZEOF_LONG__) && __BITS_PER_LONG != 8 * __SIZEOF_LONG__
> #error Inconsistent word size. Check uapi/asm/bitsperlong.h
> #endif

The if defined(__SIZEOF_LONG__) is also unnecessary as that is always present
with the supported kernel compilers.  So we can drop one level of ifdeffery.

Testing __CHAR_BIT__ == 8 would again test the compiler implementation and not
the UAPI headers, so I'd rather not do it. Using __CHAR_BIT__ in the test is
done for consistency with the generic implementation.


Thomas

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Arnd Bergmann]

On Mon, Jan 19, 2026, at 11:56, Thomas Weißschuh wrote:
> On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:
>> 
>> Don't you need a check that it isn't wrong on a user system?
>> Which is what I thought it was doing.
>
> Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
> being tested here. If they work in the kernel build I assume they also work
> in userspace.

I think You could just move check into include/asm-generic/bitsperlong.h
to make this more obvious with the #ifdef __KERNEL__, and remove the
disabled check from my original version there.

      Arnd

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

On Mon, Jan 19, 2026 at 01:45:04PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 19, 2026, at 11:56, Thomas Weißschuh wrote:
> > On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:
> >> 
> >> Don't you need a check that it isn't wrong on a user system?
> >> Which is what I thought it was doing.
> >
> > Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
> > being tested here. If they work in the kernel build I assume they also work
> > in userspace.
> 
> I think You could just move check into include/asm-generic/bitsperlong.h
> to make this more obvious with the #ifdef __KERNEL__, and remove the
> disabled check from my original version there.

Ok. I'd like to keep your existing test though, as it tests something different
and it would be nice to have that too at some point.


Thomas

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Arnd Bergmann]

On Mon, Jan 19, 2026, at 14:41, Thomas Weißschuh wrote:
> On Mon, Jan 19, 2026 at 01:45:04PM +0100, Arnd Bergmann wrote:
>> On Mon, Jan 19, 2026, at 11:56, Thomas Weißschuh wrote:
>> > On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:
>> >> 
>> >> Don't you need a check that it isn't wrong on a user system?
>> >> Which is what I thought it was doing.
>> >
>> > Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
>> > being tested here. If they work in the kernel build I assume they also work
>> > in userspace.
>> 
>> I think You could just move check into include/asm-generic/bitsperlong.h
>> to make this more obvious with the #ifdef __KERNEL__, and remove the
>> disabled check from my original version there.
>
> Ok. I'd like to keep your existing test though, as it tests something different
> and it would be nice to have that too at some point.

Sure, that works too. I wonder if one of the recent vdso cleanups
also happened to address the problem with the incorrect BITS_PER_LONG
being visible in the vdso code. Maybe we can already turn that on again.

    Arnd

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[David Laight]

On Mon, 19 Jan 2026 15:57:49 +0100
"Arnd Bergmann" <arnd@arndb.de> wrote:

> On Mon, Jan 19, 2026, at 14:41, Thomas Weißschuh wrote:
> > On Mon, Jan 19, 2026 at 01:45:04PM +0100, Arnd Bergmann wrote:  
> >> On Mon, Jan 19, 2026, at 11:56, Thomas Weißschuh wrote:  
> >> > On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:  
> >> >> 
> >> >> Don't you need a check that it isn't wrong on a user system?
> >> >> Which is what I thought it was doing.  
> >> >
> >> > Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
> >> > being tested here. If they work in the kernel build I assume they also work
> >> > in userspace.  
> >> 
> >> I think You could just move check into include/asm-generic/bitsperlong.h
> >> to make this more obvious with the #ifdef __KERNEL__, and remove the
> >> disabled check from my original version there.  
> >
> > Ok. I'd like to keep your existing test though, as it tests something different
> > and it would be nice to have that too at some point.  
> 
> Sure, that works too. I wonder if one of the recent vdso cleanups
> also happened to address the problem with the incorrect BITS_PER_LONG
> being visible in the vdso code. Maybe we can already turn that on again.

There is vdso/bits.h, but everything actually includes linux/bits.h first.

I was wondering what happens if you are actually using the 'uapi' headers
to build programs (may nolibc ones).
On x86-64, 'gcc foo.c' might work, but 'gcc -m32 foo.c' will find exactly
the same headers and go badly wrong unless everything is based on
compiler defines.

An assert (of some kind) that checks the pre-processor BITS_PER_LONG
constant actually matches sizof (long) seems reasonable for all build.
The alternative is to (somehow) manage to avoid needing a pre-processor
constant at all, moving everything to 'integer constant expressions'
instead (good luck with that...).

I'm most of the way through a 'de-bloat' patchset for bits.h.
I'm sure there is a good reason why GENMASK(hi, lo) isn't defined
as '((type)2 << hi) - ((type)1 << lo)'.
Since that definition doesn't need the bit-width in any form.
(Just beat up any static checker that objects to '2 << hi' being zero.)
I've only made that change for ASM files - IIRC the assembler only
supports one size of signed integer.

	David

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

On Mon, Jan 19, 2026 at 05:47:30PM +0000, David Laight wrote:
> On Mon, 19 Jan 2026 15:57:49 +0100
> "Arnd Bergmann" <arnd@arndb.de> wrote:
> 
> > On Mon, Jan 19, 2026, at 14:41, Thomas Weißschuh wrote:
> > > On Mon, Jan 19, 2026 at 01:45:04PM +0100, Arnd Bergmann wrote:  
> > >> On Mon, Jan 19, 2026, at 11:56, Thomas Weißschuh wrote:  
> > >> > On Mon, Jan 19, 2026 at 10:37:58AM +0000, David Laight wrote:  
> > >> >> 
> > >> >> Don't you need a check that it isn't wrong on a user system?
> > >> >> Which is what I thought it was doing.  
> > >> >
> > >> > Not really. The overrides defined by arch/*/include/uapi/asm/bitsperlong.h are
> > >> > being tested here. If they work in the kernel build I assume they also work
> > >> > in userspace.  
> > >> 
> > >> I think You could just move check into include/asm-generic/bitsperlong.h
> > >> to make this more obvious with the #ifdef __KERNEL__, and remove the
> > >> disabled check from my original version there.  
> > >
> > > Ok. I'd like to keep your existing test though, as it tests something different
> > > and it would be nice to have that too at some point.  
> > 
> > Sure, that works too. I wonder if one of the recent vdso cleanups
> > also happened to address the problem with the incorrect BITS_PER_LONG
> > being visible in the vdso code. Maybe we can already turn that on again.
> 
> There is vdso/bits.h, but everything actually includes linux/bits.h first.

These cleanups do not help unfortunately. We can skip the check for BUILD_VDSO,
but there are still plenty other places where it will break.

> I was wondering what happens if you are actually using the 'uapi' headers
> to build programs (may nolibc ones).
> On x86-64, 'gcc foo.c' might work, but 'gcc -m32 foo.c' will find exactly
> the same headers and go badly wrong unless everything is based on
> compiler defines.

I can't follow. __BITS_PER_LONG automatically adapts.

From arch/x86/include/uapi/asm/bitsperlong.h:

#if defined(__x86_64__) && !defined(__ILP32__)
# define __BITS_PER_LONG 64
#else
# define __BITS_PER_LONG 32
#endif


BITS_PER_LONG on the other hand is never exposed in the uapi headers.

> An assert (of some kind) that checks the pre-processor BITS_PER_LONG
> constant actually matches sizof (long) seems reasonable for all build.
> The alternative is to (somehow) manage to avoid needing a pre-processor
> constant at all, moving everything to 'integer constant expressions'
> instead (good luck with that...).

We do have exactly that assertion in include/asm-generic/bitsperlong.h.
(As mentioned in the patch description we are discussing)
The assertion is disabled because it fails. There are multiple places where
we build 32-bit code with a 64-bit kernel configuration.
The compat vDSO, early boot code and probably more I don't know about.
Is it ugly? Yes. Should we '#define BITS_PER_LONG __BITS_PER_LONG' at some
point? Yes. But we first need to audit all the users to check if it is safe
to do so. At some point in the future in another series.

> I'm most of the way through a 'de-bloat' patchset for bits.h.
> I'm sure there is a good reason why GENMASK(hi, lo) isn't defined
> as '((type)2 << hi) - ((type)1 << lo)'.
> Since that definition doesn't need the bit-width in any form.
> (Just beat up any static checker that objects to '2 << hi' being zero.)
> I've only made that change for ASM files - IIRC the assembler only
> supports one size of signed integer.

No idea, and I don't see the relation to the patches under discussion.


Thomas

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[H. Peter Anvin]

On 2026-01-15 23:40, Thomas Weißschuh wrote:
> The value of __BITS_PER_LONG from architecture-specific logic should
> always match the generic one if that is available. It should also match
> the actual C type 'long'.
> 
> Mismatches can happen for example when building the compat vDSO. Either
> during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> when mismatched CHECKFLAGS are inherited from the kernel build.
> 
> Add some consistency checks which detect such issues early and clearly.
> The tests are added to the UAPI header to make sure it is also used when
> building the vDSO as that is not supposed to use regular kernel headers.
> 
> The kernel-interal BITS_PER_LONG is not checked as it is derived from
> CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> deactivated check in include/asm-generic/bitsperlong.h.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> index fadb3f857f28..9d762097ae0c 100644
> --- a/include/uapi/asm-generic/bitsperlong.h
> +++ b/include/uapi/asm-generic/bitsperlong.h
> @@ -28,4 +28,18 @@
>  #define __BITS_PER_LONG_LONG 64
>  #endif
>  
> +/* Consistency checks */
> +#ifdef __KERNEL__
> +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> +#endif
> +#endif
> +
> +#ifndef __ASSEMBLER__
> +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> +#endif
> +#endif /* __KERNEL__ */
> +
>  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> 

Do we actually support any compilers which *don't* define __SIZEOF_LONG__?

	-hpa

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Thomas Weißschuh]

On Mon, Jan 19, 2026 at 07:33:13AM -0800, H. Peter Anvin wrote:
> On 2026-01-15 23:40, Thomas Weißschuh wrote:
> > The value of __BITS_PER_LONG from architecture-specific logic should
> > always match the generic one if that is available. It should also match
> > the actual C type 'long'.
> > 
> > Mismatches can happen for example when building the compat vDSO. Either
> > during the compilation, see commit 9a6d3ff10f7f ("arm64: uapi: Provide
> > correct __BITS_PER_LONG for the compat vDSO"), or when running sparse
> > when mismatched CHECKFLAGS are inherited from the kernel build.
> > 
> > Add some consistency checks which detect such issues early and clearly.
> > The tests are added to the UAPI header to make sure it is also used when
> > building the vDSO as that is not supposed to use regular kernel headers.
> > 
> > The kernel-interal BITS_PER_LONG is not checked as it is derived from
> > CONFIG_64BIT and therefore breaks for the compat vDSO. See the similar,
> > deactivated check in include/asm-generic/bitsperlong.h.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-generic/bitsperlong.h
> > index fadb3f857f28..9d762097ae0c 100644
> > --- a/include/uapi/asm-generic/bitsperlong.h
> > +++ b/include/uapi/asm-generic/bitsperlong.h
> > @@ -28,4 +28,18 @@
> >  #define __BITS_PER_LONG_LONG 64
> >  #endif
> >  
> > +/* Consistency checks */
> > +#ifdef __KERNEL__
> > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__)
> > +#if __BITS_PER_LONG != (__CHAR_BIT__ * __SIZEOF_LONG__)
> > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h
> > +#endif
> > +#endif
> > +
> > +#ifndef __ASSEMBLER__
> > +_Static_assert(sizeof(long) * 8 == __BITS_PER_LONG,
> > +	       "Inconsistent word size. Check uapi/asm/bitsperlong.h");
> > +#endif
> > +#endif /* __KERNEL__ */
> > +
> >  #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
> > 
> 
> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?

When building the kernel not. I used this pattern because it is used
further up in the file. There it makes sense as it is actually a userspace
header which needs to support all kinds of compilers.
But this new check is gated behind __KERNEL__ anyways...
For the next revision I will move it into the regular kernel-internal
bitsperlong.h. That will be less confusing and still handle the vDSO build,
due to the way our header hierarchy works.


Thomas

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[H. Peter Anvin]

On 2026-01-19 07:39, Thomas Weißschuh wrote:
>>
>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?
> 
> When building the kernel not. I used this pattern because it is used
> further up in the file. There it makes sense as it is actually a userspace
> header which needs to support all kinds of compilers.
> But this new check is gated behind __KERNEL__ anyways...
> For the next revision I will move it into the regular kernel-internal
> bitsperlong.h. That will be less confusing and still handle the vDSO build,
> due to the way our header hierarchy works.
> 

The point is that we can simply do:

#define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)

... and it will always be consistent.

	-hpa

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[Arnd Bergmann]

On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
> On 2026-01-19 07:39, Thomas Weißschuh wrote:
>>>
>>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?
>> 
>> When building the kernel not. I used this pattern because it is used
>> further up in the file. There it makes sense as it is actually a userspace
>> header which needs to support all kinds of compilers.
>> But this new check is gated behind __KERNEL__ anyways...
>> For the next revision I will move it into the regular kernel-internal
>> bitsperlong.h. That will be less confusing and still handle the vDSO build,
>> due to the way our header hierarchy works.
>> 
>
> The point is that we can simply do:
>
> #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
>
> ... and it will always be consistent.

We have discussed this before, but decided it was too early to
assume that userspace compilers are recent enough for that.
According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
gcc-4.4 has it, as do all versions of clang. Not sure what other
compilers one may encounter using Linux kernel headers.

     Arnd

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[David Laight]

On Mon, 19 Jan 2026 22:39:53 +0100
"Arnd Bergmann" <arnd@arndb.de> wrote:

> On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
> > On 2026-01-19 07:39, Thomas Weißschuh wrote:  
> >>>
> >>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?  
> >> 
> >> When building the kernel not. I used this pattern because it is used
> >> further up in the file. There it makes sense as it is actually a userspace
> >> header which needs to support all kinds of compilers.
> >> But this new check is gated behind __KERNEL__ anyways...
> >> For the next revision I will move it into the regular kernel-internal
> >> bitsperlong.h. That will be less confusing and still handle the vDSO build,
> >> due to the way our header hierarchy works.
> >>   
> >
> > The point is that we can simply do:
> >
> > #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
> >
> > ... and it will always be consistent.  
> 
> We have discussed this before, but decided it was too early to
> assume that userspace compilers are recent enough for that.
> According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
> gcc-4.4 has it, as do all versions of clang. Not sure what other
> compilers one may encounter using Linux kernel headers.

For instance MSVC doesn't define __SIZEOF_LONG__ or __x86_64__.
Unlikely to be used, but...

So you can use __SIZEOF_LONG__ if it is defined, if not hunt for
something else (possible just fixed in the installed headers).
But in the latter case (at least) a compile-time check that the
value is correct makes sense.
And that can be done portably - probable with a negative array size.

	David

> 
>      Arnd
> 

Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG

[H. Peter Anvin]

On January 20, 2026 2:03:31 AM PST, David Laight <david.laight.linux@gmail.com> wrote:
>On Mon, 19 Jan 2026 22:39:53 +0100
>"Arnd Bergmann" <arnd@arndb.de> wrote:
>
>> On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote:
>> > On 2026-01-19 07:39, Thomas Weißschuh wrote:  
>> >>>
>> >>> Do we actually support any compilers which *don't* define __SIZEOF_LONG__?  
>> >> 
>> >> When building the kernel not. I used this pattern because it is used
>> >> further up in the file. There it makes sense as it is actually a userspace
>> >> header which needs to support all kinds of compilers.
>> >> But this new check is gated behind __KERNEL__ anyways...
>> >> For the next revision I will move it into the regular kernel-internal
>> >> bitsperlong.h. That will be less confusing and still handle the vDSO build,
>> >> due to the way our header hierarchy works.
>> >>   
>> >
>> > The point is that we can simply do:
>> >
>> > #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3)
>> >
>> > ... and it will always be consistent.  
>> 
>> We have discussed this before, but decided it was too early to
>> assume that userspace compilers are recent enough for that.
>> According to godbolt.org, gcc-4.1 lacks __SIZEOF_LONG__ while
>> gcc-4.4 has it, as do all versions of clang. Not sure what other
>> compilers one may encounter using Linux kernel headers.
>
>For instance MSVC doesn't define __SIZEOF_LONG__ or __x86_64__.
>Unlikely to be used, but...
>
>So you can use __SIZEOF_LONG__ if it is defined, if not hunt for
>something else (possible just fixed in the installed headers).
>But in the latter case (at least) a compile-time check that the
>value is correct makes sense.
>And that can be done portably - probable with a negative array size.
>
>	David
>
>> 
>>      Arnd
>> 
>
>

If it doesn't define __x86_64__ it isn't API compliant at all, so it doesn't make any sense to talk about it. 

The most portable way to do it in standard C is to use <limits.h>, but that of course has the header pollution problem.