From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 78C6EC433EF for ; Wed, 12 Jan 2022 11:16:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QwCrcg08mEzLl3dvjmvtHeLlijFtrUPzFpWb7duME1s=; b=lElntSFy51sM8k bC7OyshXJ2CpX9HMaFTL+FwgJTXD+fXlPYsUuJzl2L+eRsiWOJQG9XKplRwBR8j2HN8GpprpqHxai vnBTLNAycsvk0CQzCwo3m60WU6hUKYPYBJn9ZH2lFAfOR28uaHnUNefxcue+iR3AWsf+BdzCUBZ8m vMHEe3OPxVrpnaH4eHPGU/Ix/8p64WcBvuqp+0avuBNGczK+YP0+G2hkYCDEzuItz0BQXXpReH7l/ JKOcYQfSZQAqhBsSybtdn637pA4fDhPdeB0XCplKWzVikCYsQQQlInmA751LeW89kpeasLHqGznLy 5X3CFAeLlRBndA3O0fMw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7bbT-002FXC-7M; Wed, 12 Jan 2022 11:15:43 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7bbP-002FWJ-9j for linux-arm-kernel@lists.infradead.org; Wed, 12 Jan 2022 11:15:40 +0000 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 ams.source.kernel.org (Postfix) with ESMTPS id 72F93B81CB7; Wed, 12 Jan 2022 11:15:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20B19C36AEA; Wed, 12 Jan 2022 11:15:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641986136; bh=RTTu6nWijk2G34RQ8PR1ea0narp9zXHqxMjZSrcL0co=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Hq5LE8KaLV3xNlfl8hONGT11QmqFJgF5ZZ53zgnsdO9DYAJ3B8+wjU1jSIWeFQ3/D CaFHUcDIXoppDdArCINBydMDN3XpiApt2gXzo3WfUQ9EosZsIz+fETbj6cGaJgODcQ RZjbF9LA/EWCKAuGks8VTqUhgG/KYGeeO094JHFcgGFdZ+k6BgYzvYRyQgp0IWuabE 6Amw158NYWiJ4GIMYCwvGg+6cm48+dwbs/dP2cMG/t24qKzlZsJcARwnFtoH8cDJjI ORDJ0PD0+aoOGK4FPG7XBpY4YizNUp6zImN53U/p5QaZfcKlKu0EVwLvcYWDLCGCVV ObzsbCCfB0d5Q== Message-ID: Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h From: Jeff Layton To: Arnd Bergmann , Christoph Hellwig Cc: Guo Ren , the arch/x86 maintainers , Linux ARM , Linux Kernel Mailing List , "open list:BROADCOM NVRAM DRIVER" , Parisc List , linuxppc-dev , linux-s390 , sparclinux , linux-arch , "J. Bruce Fields" Date: Wed, 12 Jan 2022 06:15:33 -0500 In-Reply-To: References: <20220111083515.502308-1-hch@lst.de> <20220111083515.502308-5-hch@lst.de> <20220112075609.GA4854@lst.de> User-Agent: Evolution 3.42.2 (3.42.2-1.fc35) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220112_031539_670253_384735E7 X-CRM114-Status: GOOD ( 31.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 2022-01-12 at 09:28 +0100, Arnd Bergmann wrote: > On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig wrote: > > > > On Tue, Jan 11, 2022 at 04:33:30PM +0100, Arnd Bergmann wrote: > > > This is a very subtle change to the exported UAPI header contents: > > > On 64-bit architectures, the three unusable numbers are now always > > > shown, rather than depending on a user-controlled symbol. > > > > Well, the change is bigger and less subtle. Before this change the > > constants were never visible to userspace at all (except on mips), > > because the #ifdef CONFIG_64BIT it never set for userspace builds. > > I suppose you mean /always/ visible here, with that ifndef. > > > > This is probably what we want here for compatibility reasons, but I think > > > it should be explained in the changelog text, and I'd like Jeff or Bruce > > > to comment on it as well: the alternative here would be to make the > > > uapi definition depend on __BITS_PER_LONG==32, which is > > > technically the right thing to do but more a of a change. > > > > I can change this to #if __BITS_PER_LONG==32 || defined(__KERNEL__), > > but it will still be change in what userspace sees. > > Exactly, that is the tradeoff, which is why I'd like the flock maintainers > to say which way they prefer. We can either do it more correctly (hiding > the constants from user space when they are not usable), or with less > change (removing the incorrect #ifdef). Either way sounds reasonable > to me, I mainly care that this is explained in the changelog and that the > maintainers are aware of the two options. > I don't have a strong opinion here. If we were taking symbols away that were previously visible to userland it would be one thing, but since we're just adding symbols that may not have been there before, this seems less likely to break anything. I probably lean toward Christoph's original solution instead of keeping the conditional definitions. It's hard to imagine there are many programs that care whether these other symbols are defined or not. You can add this to the original patch: Acked-by: Jeff Layton _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel