From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 249842D9EEF for ; Mon, 19 Jan 2026 10:06:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768817184; cv=none; b=GicGgphWH927XBwiU76oOrI1X+XAU00pONOKJMC2rV90etF4O36HB8wJMxRl8XKxXbcZr+FtJdchJ6u0aWs/NhZy6iAbz7V+GZ1WacuUHEVfHCzs0L1Vwi4Emtbcbot6N0MxT9tZ6eI74wJ3FP5YcoC5feoXdAWK+O6rHrHFNqs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768817184; c=relaxed/simple; bh=1JkATqi5wAX+Tb/87K06CYv0cw7OmX176NC/mF093QE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=LIzwKgVVTfI3kcZbhmk3RwSl4wVhH+jjz2d78tF9pZcj3mBEtdUCo6t0+b7odufUUoJ9yma3WX37AETTPqHihQ0ydB940aK2tzOHA//G7KT5SVmvWyzc3STeQnaU1ovq5m5bL8a/NLAkE6TnM2oo0axHfrUXHFVncEjGAjvdZvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GNId2tL4; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GNId2tL4" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-47ee974e230so33016955e9.2 for ; Mon, 19 Jan 2026 02:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768817181; x=1769421981; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=sqVWadMkJ0xV7b+9+R2K7XfNBOxyor4uthrrFNDywHI=; b=GNId2tL4UUadX1eRxP+Jav/HOUdQyFp8nhdDul70ZA7S7Us41CtEWt9VRcJg4nKhdn uPxukOVDj0Wq0KtfC9SZxdVEksPnLerG0W07HYK9SPp4w7rDoTOO0ynmwMA4GlbOqIoP ZGaRp5oCLyQBRCAv9LX3KgM1apjp9JT9BvI6WcXt8+6ZC+jvsVLCqkr2nhzP0TCF9P1X LWsncDVpjX10Equ2qlufyi9LDiAx8gd9JVE1vchGqVXgksD2vFfFz3NELiV1IKRHk4XI l0ZPXxqbiwZ0uXOi3xYcbXzyuFWai5zF0SnyyFiyRVk5KAa31l1M6/1bREstapugS3hK FuIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768817181; x=1769421981; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sqVWadMkJ0xV7b+9+R2K7XfNBOxyor4uthrrFNDywHI=; b=bwq45mBxsQwtG5WZ2Y8Y/MmldGeiADum65w6fP/1dNP4YSwjgUPXZheicquVZBtkkz mwEU+OwE5BKEsDDYeY5oDaWn84dlONlev32kk9gdLfyPHxDITHk68lcMRkY+iLCXpoTD mcii/HYZoZNW9YzfEEDF2q4UB9wn7BCWPMGM3mI7lZQHEGnRo6h529ZG+8t6ueNfqrER Stql+KbOH3FKgVpLjvTzqJnNd7nSHLW6upmuvVw0fLeyonwvj1VAoqjmHB7eouAlFUIq 3r4z5jS8QlkP0BrdeBr37Zh6J8VwNDMKV9MUIZRNXPgO8HHdlN/JN3kJjtrORT7ShP3k z58w== X-Forwarded-Encrypted: i=1; AJvYcCW0ntkSJ0bqp8VttCfySu2KgHKNWL36zpgzY+IZ/umOYfddktnGY/HvJ8TyTr/9KM0ZWo2huTzWTFlOZsA=@vger.kernel.org X-Gm-Message-State: AOJu0YzC4Qi6i2xoOBHeNQL9P6mg4/S91asaw5MfIwjByUXsJ5cK+Au7 DQNDcHnhwQnqoFlbDO76mu81hCMeTOaVPVxVCfQtfDhYHER61uXIyXI3 X-Gm-Gg: AY/fxX66DN59B5NEl82DROdyf8/yqxQGEPW2ONw2qBxfHRD7vFSoef7CGx6ZgVYR9Q5 vue8OyOXxymHiKed+W4LWkxZx76n7EuSXTxKW7TVRPHECujQzfGPXv2i1OAZtxAnC2x4NQJsHj2 6muNmwIYnAoIW3hwkLnzHIuZvH9R7fWk/SKeDNKoS4HOhy8lrV2YnUmtg9Y5QxRToZv/YxtYTha UwvIZm65o0eVSiOusq3Ep4HQaGoEI5qt1wYyuLWfXhMeJuFvfZr5yzfhYRjjR1Hj54szwkON5Uq rTRjtBuhpKZNYbGUlJsRgyejX45+ZR7Eolpayvp369a+t0NfWwpEffTfTlMjl/wGILir3khyXTV 28tKxFJfoZ3IgVxg0Vt1WCD2/GQsGTWkvVhdLuOc650cvD8pJ8XRyJcj801a9NeMAfIxRYuBuUw FYT2WhYac7eq8kYNHyAVF9UJYX417M85QwSoI8097lSj09W4L77u/b X-Received: by 2002:a05:600c:5285:b0:45d:d97c:236c with SMTP id 5b1f17b1804b1-4801e33c1e1mr121349185e9.21.1768817181059; Mon, 19 Jan 2026 02:06:21 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801e80c477sm213350375e9.0.2026.01.19.02.06.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 02:06:20 -0800 (PST) Date: Mon, 19 Jan 2026 10:06:19 +0000 From: David Laight To: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= Cc: "David S. Miller" , Andreas Larsson , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Arnd Bergmann , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , 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 Message-ID: <20260119100619.479bcff3@pumpkin> In-Reply-To: <20260116-vdso-compat-checkflags-v1-4-4a83b4fbb0d3@linutronix.de> References: <20260116-vdso-compat-checkflags-v1-0-4a83b4fbb0d3@linutronix.de> <20260116-vdso-compat-checkflags-v1-4-4a83b4fbb0d3@linutronix.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 16 Jan 2026 08:40:27 +0100 Thomas Wei=C3=9Fschuh 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'. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Signed-off-by: Thomas Wei=C3=9Fschuh > --- > include/uapi/asm-generic/bitsperlong.h | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) >=20 > diff --git a/include/uapi/asm-generic/bitsperlong.h b/include/uapi/asm-ge= neric/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 > =20 > +/* Consistency checks */ > +#ifdef __KERNEL__ > +#if defined(__CHAR_BIT__) && defined(__SIZEOF_LONG__) > +#if __BITS_PER_LONG !=3D (__CHAR_BIT__ * __SIZEOF_LONG__) > +#error Inconsistent word size. Check uapi/asm/bitsperlong.h > +#endif > +#endif > + > +#ifndef __ASSEMBLER__ > +_Static_assert(sizeof(long) * 8 =3D=3D __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 !=3D __BITS= _PER_LONG))]; David > +#endif > +#endif /* __KERNEL__ */ > + > #endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */ >=20