public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Arnd Bergmann <arnd@arndb.de>, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG
Date: Mon, 19 Jan 2026 10:37:58 +0000	[thread overview]
Message-ID: <20260119103758.3afb5927@pumpkin> (raw)
In-Reply-To: <20260119111037-4decf57f-2094-4fac-bcf4-03506791b197@linutronix.de>

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 */  


  reply	other threads:[~2026-01-19 10:38 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-16  7:40 [PATCH 0/4] vDSO: Use 32-bit CHECKFLAGS for compat vDSO Thomas Weißschuh
2026-01-16  7:40 ` [PATCH 1/4] sparc64: vdso: " Thomas Weißschuh
2026-01-16  7:50   ` Arnd Bergmann
2026-01-16  7:40 ` [PATCH 2/4] x86/vdso: " Thomas Weißschuh
2026-01-16  7:49   ` Arnd Bergmann
2026-01-16  8:09     ` Thomas Weißschuh
2026-01-17 22:02       ` H. Peter Anvin
2026-01-17 22:05   ` Thomas Gleixner
2026-01-19  7:20     ` Thomas Weißschuh
2026-01-19 15:33       ` H. Peter Anvin
2026-01-16  7:40 ` [PATCH 3/4] s390/vdso: Trim includes in linker script Thomas Weißschuh
2026-01-16  7:45   ` Arnd Bergmann
2026-01-16  8:15     ` Thomas Weißschuh
2026-01-17 15:22   ` Heiko Carstens
2026-01-16  7:40 ` [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG Thomas Weißschuh
2026-01-16  7:46   ` Arnd Bergmann
2026-01-19 10:06   ` David Laight
2026-01-19 10:13     ` Thomas Weißschuh
2026-01-19 10:37       ` David Laight [this message]
2026-01-19 10:56         ` Thomas Weißschuh
2026-01-19 12:45           ` Arnd Bergmann
2026-01-19 13:41             ` Thomas Weißschuh
2026-01-19 14:57               ` Arnd Bergmann
2026-01-19 17:47                 ` David Laight
2026-01-20  7:23                   ` Thomas Weißschuh
2026-01-19 15:33   ` H. Peter Anvin
2026-01-19 15:39     ` Thomas Weißschuh
2026-01-19 21:12       ` H. Peter Anvin
2026-01-19 21:39         ` Arnd Bergmann
2026-01-20 10:03           ` David Laight
2026-01-20 12:01             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260119103758.3afb5927@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=agordeev@linux.ibm.com \
    --cc=andreas@gaisler.com \
    --cc=arnd@arndb.de \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=svens@linux.ibm.com \
    --cc=tglx@kernel.org \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox