From: Christian Brauner <email@example.com>
To: Al Viro <firstname.lastname@example.org>
Cc: David Howells <email@example.com>,
firstname.lastname@example.org, Arnd Bergmann <email@example.com>,
Subject: Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2]
Date: Fri, 17 May 2019 09:01:42 +0200 [thread overview]
Message-ID: <F67AF221-C576-4424-88D7-7C6074D0A6C6@brauner.io> (raw)
On May 16, 2019 6:50:22 PM GMT+02:00, Al Viro <firstname.lastname@example.org> wrote:
>On Thu, May 16, 2019 at 06:31:52PM +0200, Christian Brauner wrote:
>> On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote:
>> > On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote:
>> > >
>> > > Hi Linus, Al,
>> > >
>> > > Here are some patches that make changes to the mount API UAPI and
>> > > them really need applying, before -rc1 - if they're going to be
>> > > all.
>> > I'm fine with 2--4, but I'm not convinced that cloexec-by-default
>> > makes any sense. Could somebody give coherent arguments in favour
>> > abandoning the existing conventions?
>> So as I said in the commit message. From a userspace perspective it's
>> more of an issue if one accidently leaks an fd to a task during exec.
>> Also, most of the time one does not want to inherit an fd during an
>> exec. It is a hazzle to always have to specify an extra flag.
>> As Al pointed out to me open() semantics are not going anywhere.
>> no argument there at all.
>> But the idea of making fds cloexec by default is only targeted at fds
>> that come from separate syscalls. fsopen(), open_tree_clone(), etc.
>> all return fds independent of open() so it's really easy to have them
>> cloexec by default without regressing anyone and we also remove the
>> for a bunch of separate flags for each syscall to turn them into
>> cloexec-fds. I mean, those for syscalls came with 4 separate flags to
>> able to specify that the returned fd should be made cloexec. The
>> way around, cloexec by default, fcntl() to remove the cloexec bit is
>> saner imho.
>Re separate flags - it is, in principle, a valid argument. OTOH, I'm
>sure if they need to be separate - they all have the same value and
>I don't see any reason for that to change...
One last thing I'd like to point out is that
we already have syscalls and ioctls that
return cloexec fds. So the consistency
argument is kinda dead.
If you still prefer to have cloexec flags
for the 4 new syscalls then yes,
if they could at least all have the same name
(FSMOUNT_CLOEXEC?) that would be good.
>Only tangentially related, but I wonder if something like
>would be a more useful approach... That kind of open-coded loops is
>rare in userland and kernel-side code can do them much cheaper.
> /* that exec is sensitive */
> /* we don't want anything past stderr here */
> close_range(3, ~0U);
>on the userland side of thing. Comments?
Said it before but, the list was mistyped so again:
I think that's a great idea.
I have a prototype for close_range(start, end, flags).
I'll wait after rc1 and then send it out.
next prev parent reply other threads:[~2019-05-17 7:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 11:52 [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2] David Howells
2019-05-16 11:52 ` [PATCH 1/4] uapi, fs: make all new mount api fds cloexec by default " David Howells
2019-05-16 11:52 ` [PATCH 2/4] uapi, fsopen: use square brackets around "fscontext" " David Howells
2019-05-16 11:52 ` [PATCH 3/4] uapi, x86: Fix the syscall numbering of the mount API syscalls " David Howells
2019-05-16 13:01 ` Christian Brauner
2019-05-16 11:52 ` [PATCH 4/4] uapi: Wire up the mount API syscalls on non-x86 arches " David Howells
2019-05-16 13:01 ` Christian Brauner
2019-05-16 14:56 ` Geert Uytterhoeven
2019-05-16 14:59 ` Christian Brauner
2019-05-16 16:22 ` [PATCH 0/4] uapi, vfs: Change the mount API UAPI " Al Viro
2019-05-16 16:31 ` Al Viro
2019-05-16 16:31 ` Christian Brauner
2019-05-16 16:50 ` Al Viro
2019-05-16 17:01 ` Christian Brauner
2019-05-16 20:23 ` Dmitry V. Levin
2019-05-17 6:54 ` Christian Brauner
2019-05-17 7:01 ` Christian Brauner [this message]
2019-05-17 7:13 ` David Howells
2019-05-17 7:25 ` Miklos Szeredi
2019-05-17 7:27 ` Christian Brauner
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).