From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (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 93337343216 for ; Sun, 8 Feb 2026 22:27:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770589649; cv=none; b=IbanIPh08Cs+KxUN2O5DqNN0QvftPd74w113Cf5Ga9UkqnTiSG7OMO3vB4zG5ftbf3sIzj4VslqGscm8ic1JDYAGtJa4VlvM39ZCYLlhI7tS0VxkaQJlqA+D+82tAxoOm2Qn7tzMgxYN13WB5xMVxMchsIitQl5s3PgLPUJ3hJ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770589649; c=relaxed/simple; bh=JqQfkRKGgXEuMyoMTMD+BHm4yYbh9FilgzrH+YKQPD8=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H3umMd6qbuO0DZXTV2lGaXN7XaVw50l+Xi1dlILWa2eQ1m5N5xrMZjgg5QcVzOf+tW79SnFx8suHQQ44+yyAq4sVkvPgY+FBgtYIc+c0gsQ2YiVYN22SqpyuMWgdYVXw3qkAoXW4NfQ2lhzuQykV+ac43iig+vsmBW6hgd/PnXk= 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=PyqIKqdt; arc=none smtp.client-ip=209.85.128.65 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="PyqIKqdt" Received: by mail-wm1-f65.google.com with SMTP id 5b1f17b1804b1-48336a6e932so5102325e9.3 for ; Sun, 08 Feb 2026 14:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770589647; x=1771194447; 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=ktWT/NVGItdmNF1PY1FSsYjrY9j/tnKNE9OQGN+tNog=; b=PyqIKqdtoWz+HvG5e9EruQe3WTdNfeicea1H3aE+7ZaUNAXj1GDey7S17SxYl52BSU MzTq+3frUGAhwoC6cGyDn9EDZx+j4BXSDCEnw41db7pT5taBIAbgVs2/n98luyiXm2m9 0fNnrqnorzRBZA6q03F64RDCcDyx0M2hiDjO6SMm93eAeDA3DGrem0+rCyHo6qecfxDu 8Iqtn9rBdEuNUsbeVczR7pGv9JcVbbdkw0IhgxhvpWR2pT3M+mplHyOcnZUdKwhLG8nu 1nwngPIWWo7jnC+vV9ZcgOGstBLZhPAPe3i0zY8poHBlE/7d6pE2znf8j0r3ZItv07ue Nykw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770589647; x=1771194447; 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=ktWT/NVGItdmNF1PY1FSsYjrY9j/tnKNE9OQGN+tNog=; b=JQ7zB8vwIrnK9TsxQXuX2TxwvKTZV1BE6UY5v0lhCu/7c0iKfBNBoD/3JU5hbLwdPI vXQ026JgMtnD5sVsBh8jUk30S5wsTRC3X2vNzvPdBJzTL7oUEAIuR5Sx5rdCdlAkllBR oiCDAdAYdw9bRHNaM/OacxSXwzYlqhSzy/WR+Y1VEQHRfL15cO5lf0jutxaPwE2rtw98 dszeCuqkZN9e9xqpfjhBzCwYtLWV0Ev0bOqsuIsbjoEEUYZkYdRFvEfQ35kCP8D5jQL2 6Wtc8XwVtGe3vUZ7gJVwlAxGuASCkOWugQSx+ZTgGiIzNwciL70E5W8wNqHOqXAWc4WY wW0g== X-Forwarded-Encrypted: i=1; AJvYcCU9BEXBtxkjMlL67B5FDIum1IvQ/TtmjhNGZ1lYs6V4WT+vqEOr9Kbjp8XtnE9n1ocIBY4/foMNUWa6r8A=@vger.kernel.org X-Gm-Message-State: AOJu0YxzE9xvLVIDvSJpYi2t0eBzIlRSsLP/CFltvqwaevaLudMxK1fS F96kjFdVoGpTa5Ggp2RXSpIn2ccGakVg/RJXuUML5x1MluOQFiHqh+oI X-Gm-Gg: AZuq6aKTa7Dg2xjLy2PGBTMBv6PS2T+G2vQmU/vtIvfnymVRVQPEag7Q0TGDCX1URKZ Rdy3ZR9qRCliaFS8T3AqDt8IqlZxXGkF8n7mdM9hAc92uXN3HNHA7eEXTKrihYVZkDSAkCwqQ1Q ewERPo9MFx2Xwvjchm62GLaOe8halNN48NPldR8TMayH+c0q42NUeOnrIeRZlRmvLkow9idhFfh A8ucRHfqFFNEQNq+TozdKW2aB3+0mC+Au0yKC3CJDRLfAIWR3W/OXr5UF0UB4AicG5COU1kbaFP bGOFHfr+PDLlxFK4X2Vv3invAiEaM4bj8UY+GXyfoiTlZzlrd0zFN1EscGFWvRgPwsyw1FM+RmA Sf9zxs9I0IdsP3Xb4IwF+z8sB8O3vhPR0oUvnEHctGegsgH7l7DHCr8bK/NsOVvCCL2eU9SA8wB azvrrMurR4RlRwGadsN95+6VzBCblaVRSimgN2ObrGfw7w2BOfiT+a8zXqKhU+B88= X-Received: by 2002:a05:600c:4745:b0:47e:e48b:506d with SMTP id 5b1f17b1804b1-483201e4b18mr150839385e9.16.1770589646663; Sun, 08 Feb 2026 14:27:26 -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-437699bc1cdsm7935312f8f.7.2026.02.08.14.27.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Feb 2026 14:27:26 -0800 (PST) Date: Sun, 8 Feb 2026 22:27:24 +0000 From: David Laight To: Yury Norov Cc: Nathan Chancellor , Greg Kroah-Hartman , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Mathieu Desnoyers , Arnd Bergmann , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Yury Norov , Lucas De Marchi , Jani Nikula , Vincent Mailhol , Andy Shevchenko , Kees Cook , Andrew Morton Subject: Re: [PATCH next 10/14] bits: Fix assmebler expansions of GENMASK_Uxx() and BIT_Uxx() Message-ID: <20260208222724.6e2dd07e@pumpkin> In-Reply-To: References: <20260121145731.3623-1-david.laight.linux@gmail.com> <20260121145731.3623-11-david.laight.linux@gmail.com> <20260208114214.270b4982@pumpkin> 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=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 8 Feb 2026 16:20:45 -0500 Yury Norov wrote: > On Sun, Feb 08, 2026 at 11:42:14AM +0000, David Laight wrote: > > On Sat, 7 Feb 2026 22:31:34 -0500 > > Yury Norov wrote: > > > > > On Wed, Jan 21, 2026 at 02:57:27PM +0000, david.laight.linux@gmail.com wrote: > > > > From: David Laight > > > > > > > > The assembler only supports one type of signed integers, so expressions > > > > using BITS_PER_LONG (etc) cannot be guaranteed to be correct. > > > > > > > > Use ((2 << (h)) - (1 << (l))) for all assembler GENMASK() expansions and > > > > add definitions of BIT_Uxx() as (1 << (nr)). > > > > > > > > Note that 64bit results are (probably) only correct for 64bit builds > > > > and 128bits results will never be valid. > > > > > > And this important note will sink in git history. > > > > At least it isn't only in the email archives. > > I can put it in a comment. > > > > > > Signed-off-by: David Laight > > > > > > This has been discussed in details when those GENMASK_Uxx() were > > > introduced. Assembler doesn't support C types, and can't provide any > > > guarantees. It may only confuse readers when they see something like > > > GENMASK_U8() in the assembler code, and there's nothing on behalf of > > > that declaration to enforce the limitation. > > > > It won't be in asm code, the asm code will be expanding a constant > > from a C header file. > > It can be included and preprocessed well in any .S file: > > #define GENMASK_TYPE(t, h,l) ((2 << (h)) - (1 << (l))) > #define GENMASK(h, l) GENMASK_TYPE(unsigned long, (h), (l)) > > .section .rodata > fmt: > .string "GENMASK(63,60) = 0x%016llx\n" > > .text > .globl main > .type main, @function > > main: > push %rbp > mov %rsp, %rbp > > lea fmt(%rip), %rdi > mov $GENMASK(63,60), %rsi > xor %rax, %rax > call printf@PLT > > mov $0, %eax > pop %rbp > ret > > In C this doesn't work at all as it throws overflow. It doesn't even > work in asm volatile section. Indeed - that I'm not trying to use that expression in C. Although it will work for non-constants. For constants you'd have to use ((1 << hi) - 1) * 2) + 1. While I'm pretty sure the compiler will convert it to the former, both generate worse code in some corner cases. The issue at the moment is that you get these definitions from uapi/linux/bits.h #define __GENMASK(h, l) (((~_UL(0)) << (l)) & (~_UL(0) >> (__BITS_PER_LONG - 1 - (h)))) #define __GENMASK_ULL(h, l) (((~_ULL(0)) << (l)) & (~_ULL(0) >> (__BITS_PER_LONG_LONG - 1 - (h)))) For .S files both _UL() and _ULL() are null, so these are: #define __GENMASK(h, l) (((~0) << (l)) & (~0 >> (__BITS_PER_LONG - 1 - (h)))) #define __GENMASK_ULL(h, l) (((~0) << (l)) & (~0 >> (__BITS_PER_LONG_LONG - 1 - (h)))) Which makes them identical except for the two constants. On 32bit builds the two constants are different which means that while __GENMASK(5, 2) and __GENMASK_ULL(5,2) should have the same value they may not (depending exactly how the assembler evaluates constant expressions). Assuming that either __BITS_PER_LONG or __BITS_PER_LONG_LONG has anything to do with the number of bits in the assembler's expression evaluator doesn't seem right at all. David > > > > That's why we didn't add fake C types support in the assembler. Unless > > > we find a way to enforce C types capacity in assembler(s), let's keep > > > those macros C-only. > > > > But GENMASK_ULL() was already there and would generate invalid values > > (for small values) on 32bit. > > You continuously repeat that GENMASK_ULL() generates wrong values, but > never submitted a fix. > > Anyways, if you think GENMASK_ULL() is not needed in assembler, it's > even harder to advocate fixed-type flavors. > > > The only reason for defining these for assembler is so that .h files > > that use the definitions can be used in .S files. > > As soon as any of the BIT_Unn() get used the asm code is likely to > > try to expand them. > > The only reason for fixed-type GENMASK() and BIT() is strict > parameters checking. This is not possible in assembler. > > Thanks, > Yury