Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2157144iof; Tue, 7 Jun 2022 21:40:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/HdbtdNPyizoQ8vp3bJwnTT6hc8HJpvjC+xUCDzdj7F5suCwX7WzRWtLYWY/6I67R3gYt X-Received: by 2002:a63:3143:0:b0:3fc:6078:7e0f with SMTP id x64-20020a633143000000b003fc60787e0fmr28244195pgx.272.1654663210137; Tue, 07 Jun 2022 21:40:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654663210; cv=none; d=google.com; s=arc-20160816; b=CQDeI9bv4Zu9jY6aON1ysICMxSyBGUuClNkLK9XHPwfA1ZqZnJEyei4/jzN3qwY16x 48eI24w1FJ+xs90Epay3BAlxIVLdwXMD80C7AWtfeddUHXyxajrN/BRKoE8xzXjhYJNg bcEWGtKA1i7ZKxSIH2rLsLNo2TpH17BGt5K5G1eSdrZuvXkIXzjO2/5s8bBHBHgACBFc yvsQqcdnWKzbKKehYNkX+C0u7QqW61OIywAv0jd63pf09ArBLOdBcTvG024/NJIu2AW5 iv7qBKEQLadS2z91qgvkMDxUWYktZWNLzB9zoPZDMf7BTZ0NGE7xmok8jh7MofgH0ekI CCdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=s1dGqxO1pXQgwWDW18zwaQDyj0mDPSrJI8V5tQ4W3iE=; b=hGAWH4UY3DGewyGEKWBupsTrVkefYp9ZgxgIESzeB8CkbWdCepMSAY9rQ0AYJpx2wy wUxtTGm+71IUza24q72XgVFPpu43rCoafYbSuFqf+n1w1BTEqlnBNtltt7TQjwLuzkHP JXDqOG6wJkGoNTEBQzWI93W9JuRbmDttaO01Fi5Tc54PsjYBVWNEefwTvJEua/7JFCF5 iV5GaWE/I6BMhmZWWidz0swWIzYs9j9TwgJ2KVGnprWilfqeq5DVd6f3DC+3OTyEqjgD c/PS/3dLQhO7383+XHRaxAYhnmNjmatPduN8icFNqzpGlMi1tTsNIUwKgxEASVBc59dG PJ/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eEFjN7f2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l63-20020a638842000000b003fe30cc898bsi1354728pgd.664.2022.06.07.21.40.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 21:40:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=eEFjN7f2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5284F213A16; Tue, 7 Jun 2022 21:06:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1381930AbiFGWdZ (ORCPT + 99 others); Tue, 7 Jun 2022 18:33:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1380307AbiFGVQE (ORCPT ); Tue, 7 Jun 2022 17:16:04 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74D11157E8E; Tue, 7 Jun 2022 11:55:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 9AC77CE1D50; Tue, 7 Jun 2022 18:54:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 83456C385A2; Tue, 7 Jun 2022 18:54:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654628096; bh=jAuNF6M+3PV9HonytzGTV1kYObV5ikBT2owp1pOQg1U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eEFjN7f2Lk9jTr5hQpBd/m3Qnjo5B6WsdGlhNosW9Vp+rePVmsBtN/hH6HOpklIpg MVViYT/kgpGEt68Xw4FSCzpNHATWoZHoABXospJZSzZwa/lxjSc6grJI1Tdx8TFtcF uM6sI0OIYH3bjVFc8LLPQd8KUim3vlf3ChNMacXU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Slaby , Bjorn Helgaas , Linus Torvalds , Sasha Levin Subject: [PATCH 5.18 206/879] linux/types.h: reinstate "__bitwise__" macro for user space use Date: Tue, 7 Jun 2022 18:55:24 +0200 Message-Id: <20220607165008.829694453@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Linus Torvalds [ Upstream commit caa28984163cb63ea0be4cb8dbf05defdc7303f9 ] Commit c724c866bb70 ("linux/types.h: remove unnecessary __bitwise__") was right that there are no users of __bitwise__ in the kernel, but it turns out there are user space users of it that do expect it. It is, after all, in the uapi directory, so user space usage is to be expected. Instead of reverting the commit completely, let's just clarify the situation so that it doesn't happen again, and have some in-code explanations for why that "__bitwise__" still exists. Reported-by: Jiri Slaby Cc: Bjorn Helgaas Link: https://lore.kernel.org/all/b5c0a68d-8387-4909-beea-f70ab9e6e3d5@kernel.org/ Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin --- include/uapi/linux/types.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h index c4dc597f3dcf..308433be33c2 100644 --- a/include/uapi/linux/types.h +++ b/include/uapi/linux/types.h @@ -26,6 +26,9 @@ #define __bitwise #endif +/* The kernel doesn't use this legacy form, but user space does */ +#define __bitwise__ __bitwise + typedef __u16 __bitwise __le16; typedef __u16 __bitwise __be16; typedef __u32 __bitwise __le32; -- 2.35.1