Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp61057pxj; Thu, 20 May 2021 04:35:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSqKHGCZAU3qPMedtyceKwwTvDZTSTsnWOgMf36se3VFqQNYX6Nuv4DTa4stOsZvWCXWD+ X-Received: by 2002:a05:6402:19b9:: with SMTP id o25mr4335130edz.192.1621510541485; Thu, 20 May 2021 04:35:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621510541; cv=none; d=google.com; s=arc-20160816; b=z4+UUkTt3MJC3U7p/hBTsP79UBp1+1eG/v2h634inwCKDyLt75680YRb1PIUUPHSYk WSM+Aif3bifODara74Yq9vS2AMt79SHzY0BEefj6ggbYEWQxO11EQ0NglvMbYu4DhqZI 5wDLTVXHFNHPgJf4XYMkURfmQmpZRYRw2RHxalarn0IrpWBVlk3G8YIU2N27NpK1U4b4 wr9vI6i9yIl0ADxv9pKRD0yOFPCG5+IdeUpV0Mqshjl8b3G+a00Uk5IVT6yMN27xIItu M7AC9r9l436FejQIf966bcAybDZdppxWx8kl0bxXw2pR8Vn4yBII27gVpEwop2cuB+r2 +Sdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=XL4GYwsRffs8PHcjLepWClwZg5M/pooXOUDliw2NS4I=; b=s2VYJUiyglLMeGEQTw941yeGbKa/7HxpgIbT3CLp2MckhA3DAyboj4ULxAqz2hOK/W J+nTL+IR3L27zuQd820J4DF5Pcp+NDrMpOraYhCPd0agqa8oV8qyDzqcuv6KwHjxzopE 48yRN33EELkXdDtKlGx/VtbuCZdaEWzItLTGFCJoKAtVMAzcbnpYkeaVqmvZxkRyNgHi iOf5wDIREXHwbjYb1u9X8P28/wCNxC6ZMhH5xq8nuRJ9kZrMxwz3m6dsoeH+msQDBz4q hJZDiykGxdmrJx0RiAQxmudeXAKirwi/OrGxjfQladz1bKPxDkm+gqypidak6sdnEddG loWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v8si2050791edc.533.2021.05.20.04.35.17; Thu, 20 May 2021 04:35:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241387AbhETLdR (ORCPT + 99 others); Thu, 20 May 2021 07:33:17 -0400 Received: from foss.arm.com ([217.140.110.172]:47082 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239675AbhETLMq (ORCPT ); Thu, 20 May 2021 07:12:46 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4236311D4; Thu, 20 May 2021 04:11:25 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.7.235]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D94AC3F719; Thu, 20 May 2021 04:11:21 -0700 (PDT) Date: Thu, 20 May 2021 12:11:19 +0100 From: Mark Rutland To: Joe Richey Cc: trivial@kernel.org, Joe Richey , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Lorenzo Pieralisi , Mauro Carvalho Chehab , Zhangfei Gao , Zhou Wang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org, linux-accelerators@lists.ozlabs.org Subject: Re: [PATCH 0/6] Don't use BIT() macro in UAPI headers Message-ID: <20210520111119.GC17233@C02TD0UTHF1T.local> References: <20210520104343.317119-1-joerichey94@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210520104343.317119-1-joerichey94@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, May 20, 2021 at 03:43:37AM -0700, Joe Richey wrote: > From: Joe Richey > > The BIT(n) macro is used in the kernel as an alias for (1 << n). > However, it is not defined in the UAPI headers, which means that any > UAPI header files must be careful not to use it, or else the user > will get a linker error. Beware that the common definition of BIT() (in include/vdso/bits.h) is: | #define BIT(nr) (UL(1) << (nr)) That UL() can be important if `nr` is ever greater than bits per int. > For example, compiling the following program: > > #include > #include > > // Detect if FSGSBASE instructions are enabled > int main() { > unsigned long val = getauxval(AT_HWCAP2); > return !(val & HWCAP2_FSGSBASE); > } > > Results in the following likner error: > > /usr/bin/ld: /tmp/cceFpAdR.o: in function `main': > gs.c:(.text+0x21): undefined reference to `BIT' > > This patch series changes all UAPI uses of BIT() to just be open-coded. In include/uapi/linux/const.h we have an equivaleint _BITUL() macro, which I think should be used in preference of open-coding this (and is already used in a number of uapi headers). > However, there really should be a check for this in checkpatch.pl > Currently, the script actually _encourages_ users to use the BIT macro > even if adding things to UAPI. I think having something that suggests s/BIT()/_BITUL()/ under uapi would be good. Thanks, Mark. > > Running `rg "BIT\(" **/uapi/**` shows no more usage of BIT() in any > UAPI headers. Tested by building a basic kernel. Changes are trivial. > > Joe Richey (6): > x86/elf: Don't use BIT() macro in UAPI headers > KVM: X86: Don't use BIT() macro in UAPI headers > drivers: firmware: psci: Don't use BIT() macro in UAPI headers > uacce: Don't use BIT() macro in UAPI headers > media: vicodec: Don't use BIT() macro in UAPI headers > tools headers UAPI: Sync pkt_sched.h with the kernel sources > > arch/x86/include/uapi/asm/hwcap2.h | 2 +- > include/uapi/linux/kvm.h | 4 +- > include/uapi/linux/psci.h | 2 +- > include/uapi/linux/v4l2-controls.h | 22 ++--- > include/uapi/misc/uacce/uacce.h | 2 +- > tools/include/uapi/linux/kvm.h | 4 +- > tools/include/uapi/linux/pkt_sched.h | 122 ++++++++++++++++++++++++--- > 7 files changed, 130 insertions(+), 28 deletions(-) > > -- > 2.31.1 >