All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>, Guo Ren <guoren@kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 09:28:26 +0100	[thread overview]
Message-ID: <CAK8P3a1ONn=FiPU3669MjBMntS-1K5bgX4pHforUsYJ7yhwZ-g@mail.gmail.com> (raw)
In-Reply-To: <20220112075609.GA4854@lst.de>

On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig <hch@lst.de> 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.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-arch <linux-arch@vger.kernel.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Guo Ren <guoren@kernel.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 09:28:26 +0100	[thread overview]
Message-ID: <CAK8P3a1ONn=FiPU3669MjBMntS-1K5bgX4pHforUsYJ7yhwZ-g@mail.gmail.com> (raw)
In-Reply-To: <20220112075609.GA4854@lst.de>

On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig <hch@lst.de> 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.

        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Christoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>, Guo Ren <guoren@kernel.org>,
	 "the arch/x86 maintainers" <x86@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 "open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	 linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-s390 <linux-s390@vger.kernel.org>,
	 sparclinux <sparclinux@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	 Jeff Layton <jlayton@kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
Date: Wed, 12 Jan 2022 09:28:26 +0100	[thread overview]
Message-ID: <CAK8P3a1ONn=FiPU3669MjBMntS-1K5bgX4pHforUsYJ7yhwZ-g@mail.gmail.com> (raw)
In-Reply-To: <20220112075609.GA4854@lst.de>

On Wed, Jan 12, 2022 at 8:56 AM Christoph Hellwig <hch@lst.de> 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.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-12  8:28 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-11  8:35 consolidate the compat fcntl definitions Christoph Hellwig
2022-01-11  8:35 ` Christoph Hellwig
2022-01-11  8:35 ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 2/5] uapi: simplify __ARCH_FLOCK{,64}_PAD a little Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 3/5] uapi: merge the 32-bit mips struct flock into the generic one Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11 15:33   ` Arnd Bergmann
2022-01-11 15:33     ` Arnd Bergmann
2022-01-11 15:33     ` Arnd Bergmann
2022-01-12  2:08     ` Guo Ren
2022-01-12  2:08       ` Guo Ren
2022-01-12  2:08       ` Guo Ren
2022-01-12  7:56     ` Christoph Hellwig
2022-01-12  7:56       ` Christoph Hellwig
2022-01-12  7:56       ` Christoph Hellwig
2022-01-12  8:28       ` Arnd Bergmann [this message]
2022-01-12  8:28         ` Arnd Bergmann
2022-01-12  8:28         ` Arnd Bergmann
2022-01-12 11:15         ` Jeff Layton
2022-01-12 11:15           ` Jeff Layton
2022-01-12 11:15           ` Jeff Layton
2022-01-12 12:08           ` Arnd Bergmann
2022-01-12 12:08             ` Arnd Bergmann
2022-01-12 12:08             ` Arnd Bergmann
2022-01-12 16:09             ` Christoph Hellwig
2022-01-12 16:09               ` Christoph Hellwig
2022-01-12 16:09               ` Christoph Hellwig
2022-01-11  8:35 ` [PATCH 5/5] compat: consolidate the compat_flock{,64} definition Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  8:35   ` Christoph Hellwig
2022-01-11  9:52   ` David Laight
2022-01-11  9:52     ` David Laight
2022-01-11  9:52     ` David Laight
2022-01-11 15:46 ` consolidate the compat fcntl definitions Arnd Bergmann
2022-01-11 15:46   ` Arnd Bergmann
2022-01-11 15:46   ` Arnd Bergmann
2022-01-12  9:56 ` Sergey Shtylyov
2022-01-12  9:56   ` Sergey Shtylyov
2022-01-12  9:56   ` Sergey Shtylyov
  -- strict thread matches above, loose matches on Subject: below --
2022-01-31  6:49 consolidate the compat fcntl definitions v2 Christoph Hellwig
2022-01-31  6:49 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2022-01-31  6:49   ` Christoph Hellwig
2022-01-31  6:49   ` Christoph Hellwig
2022-01-31 13:38   ` Guo Ren
2022-01-31 13:38     ` Guo Ren
2022-01-31 13:38     ` Guo Ren
2022-02-01  3:02   ` Guo Ren
2022-02-01  3:02     ` Guo Ren
2022-02-01  3:02     ` Guo Ren
2022-02-01  3:07     ` Guo Ren
2022-02-01  3:07       ` Guo Ren
2022-02-01  3:07       ` Guo Ren
2021-04-12  8:55 consolidate the flock uapi definitions Christoph Hellwig
2021-04-12  8:55 ` [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h Christoph Hellwig
2021-04-12  8:55   ` Christoph Hellwig
2021-04-12  8:55   ` Christoph Hellwig
2021-04-13 15:43   ` Helge Deller
2021-04-13 15:46     ` Christoph Hellwig
2021-04-13 15:58       ` Helge Deller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK8P3a1ONn=FiPU3669MjBMntS-1K5bgX4pHforUsYJ7yhwZ-g@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=bfields@fieldses.org \
    --cc=guoren@kernel.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.