From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (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 E5BD73D523A for ; Tue, 20 Jan 2026 11:46:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768909606; cv=none; b=X29nzuf8pkhVmlEvWecBtIbOQPxAQVdZMpTA3KnAam+c5YFRYF4mNtFVMdfeP4aJwNVCSck71X5dKatV64esfwfD2NumlW72EFfTSmGWADX8d9mGuGpJKjDsm9vo2WqH0dwYBne2GOEJQYR9bHdmc/fXlajYDfqPmf8k0Fnd4Pw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768909606; c=relaxed/simple; bh=rOd9yTpdEpOmqr8gV3Zvtz93VcNjmSVSiEIE/dTz7Yg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pR2RQa1VRKeW6ZV2ZQFLWDaDPuoe2AkUHzHzDSPKQkqh9a/qHFJugmXp7JwSnxU8ATl55XmWyxv9zJqJT0opv5lIPf7kL2iLjIX+roMf3ALFJm1ZVgPiO/XzDr21ekD0GmMzZ/WcMjFstN7MAwtL2+yJJv4563f1DFkjvLuj+Uw= 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=bZHHLLQF; arc=none smtp.client-ip=209.85.208.50 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="bZHHLLQF" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-64d4d8b3ad7so8495643a12.2 for ; Tue, 20 Jan 2026 03:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768909603; x=1769514403; 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=pGTA45Ofysyie+s0KKre7pJ1MVbPnUxT25h6KktO9Bs=; b=bZHHLLQFL5zC2r6l/7dwlA5GcuIkRrOhUYwymO+RqD5YUINiHtrmLF9HIz+b1yU8Fr sYbgU388Fg9pacCxh8ZgZyOyfZxdMqxJKjGNLFdBOWbV1qxrWdwPXKrWvIncCcdILhS+ MUs2IDGnIp5H+nMpQm8dcTkEBKhp43XPlox1YIvL/0icBobdUv+uPD99sHsX/8e9g4JO 4Oj00MUxXBOkEJNngDLSzZrhLJrJJDH1L9OcFC+LCzf8vLG36oDRHvAEURxOcQ973J69 BJbkZU7C4IC3DXkhJ1ts13hlAt3S3BOnb5m6BxL5PYZzy1/hKU0zBim6MxrE1SV3YRhB UsOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768909603; x=1769514403; 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=pGTA45Ofysyie+s0KKre7pJ1MVbPnUxT25h6KktO9Bs=; b=J3YduxyX3uhwSe9d+C2TqYaqunvv5P+WFIQHcIIfc8Bj/9bX+GpnhXi8KccCDSn1VM mXgEXioR+FEnoYL6LCtd35S3vdqtHng6PXCSHYMc4vJRb+00R0HQ+efog474Cha3BkK8 0MsEJBCPoYngqctPXKGshzutjjwl4qIbPAL/Znel9XjZda5MLAGdmFlbUtvzaCC4+FdV JC8Ct7GG8jGGa7r1i2cy1Oy9AsDDa3HJmp76FX9OQ6FnScSwrsYqzm1XGMqdnv2zB7Kh TMNs2pLZHxpYs84+ofbmrGy+iB3Gt67sl4UtGCKy7hN40dVarjhfYtfgoygBiwN2+8lL nmfw== X-Forwarded-Encrypted: i=1; AJvYcCW5wttbF0EJcJHU27qgTP/GyyQWdEEIwX3ax2ji2Wkec+w2IgeyGnQ5e5S/sD/dHVXxehRQF+2V/id/76A=@vger.kernel.org X-Gm-Message-State: AOJu0YycJjeV6xTG//Z+Od7GLfTNjcsTw6eCggVOgnMu99EVtJOEzxgY EAjfcw9X+YuOx/hVBXO1dY4TTqFws79MmYmzujMYevxPv+Z2n8vHC+zTXs7Xig== X-Gm-Gg: AZuq6aLHSiaGqASH+Q2Iy8TZuNroh6Fu4Vc8IDB5aEa8TniiC6GWiO5af6agtKyzqgp zVxQ3060hIXC246bp6tMsnVglnFuv3sAAfsDxhyWyilQOxp8UUSmqqDtMHkLGVGttQzfCPRFZPj ypzPEpVIVdcEgAJ8m3EAfPD2d9hl9Q52tW2kP3cOcWPTkBZSSBkqCUqJR/A6r4oWCJH9mMSTEyi hSvOlVpGxnwcOn6+kGmK3myBIJFiQLLxj6GbbKI1chl9+f5MeKiKhyhu3y5IIbqmyRGZof2BN55 G6qM7ka+73FrBxE9QuLhQra/E+Ys9zjMFIvWhoBMWPLw2TXMNVID3ioVh9D/99sEtUikf4MbyPt gkwTPHFz9+3276qvw7nZyN6xXshUNkO7R+F9px1aFjycOyIGzeMt1zULWBAlR0lkYDH2aPc7RTQ GMOkTdOd6cjVSlr/yEF5jI6lRcY8U6OJe51n76RSewA5zB2EXuiEHR X-Received: by 2002:a05:6000:4202:b0:432:a9fb:68f8 with SMTP id ffacd0b85a97d-4356a02643dmr16216419f8f.1.1768903412929; Tue, 20 Jan 2026 02:03:32 -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 ffacd0b85a97d-43569997f41sm27420500f8f.38.2026.01.20.02.03.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 02:03:32 -0800 (PST) Date: Tue, 20 Jan 2026 10:03:31 +0000 From: David Laight To: "Arnd Bergmann" Cc: "H. Peter Anvin" , Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , "David S . Miller" , "Andreas Larsson" , "Andy Lutomirski" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, "Heiko Carstens" , "Vasily Gorbik" , "Alexander Gordeev" , "Christian Borntraeger" , "Sven Schnelle" , sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, Linux-Arch , linux-s390@vger.kernel.org Subject: Re: [PATCH 4/4] asm-generic/bitsperlong.h: Add sanity checks for __BITS_PER_LONG Message-ID: <20260120100331.1f57aa99@pumpkin> In-Reply-To: <7b10344c-bb71-44fb-a391-32f7784db0e6@app.fastmail.com> References: <20260116-vdso-compat-checkflags-v1-0-4a83b4fbb0d3@linutronix.de> <20260116-vdso-compat-checkflags-v1-4-4a83b4fbb0d3@linutronix.de> <1a77fda4-3cf6-4c19-aa36-b5f0e305b313@zytor.com> <20260119163559-b20b14d7-56ca-4f17-8800-83f618d778b8@linutronix.de> <7b10344c-bb71-44fb-a391-32f7784db0e6@app.fastmail.com> 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 Mon, 19 Jan 2026 22:39:53 +0100 "Arnd Bergmann" wrote: > On Mon, Jan 19, 2026, at 22:12, H. Peter Anvin wrote: > > On 2026-01-19 07:39, Thomas Wei=C3=9Fschuh wrote: =20 > >>> > >>> Do we actually support any compilers which *don't* define __SIZEOF_LO= NG__? =20 > >>=20 > >> 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 users= pace > >> 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 b= uild, > >> due to the way our header hierarchy works. > >> =20 > > > > The point is that we can simply do: > > > > #define __BITS_PER_LONG (__SIZEOF_LONG__ << 3) > > > > ... and it will always be consistent. =20 >=20 > 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 >=20 > Arnd >=20