LKML Archive on
help / color / mirror / Atom feed
From: Christian Brauner <>
To: Linus Torvalds <>
Cc: Alexey Dobriyan <>,,,,,
	Linux List Kernel Mailing <>,
	linux-fsdevel <>
Subject: Re: [PATCH v2 0/2] close_range()
Date: Fri, 24 May 2019 12:27:58 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 23, 2019 at 02:34:31PM -0700, Linus Torvalds wrote:
> On Thu, May 23, 2019 at 11:22 AM Alexey Dobriyan <> wrote:
> >
> > > This is v2 of this patchset.
> >
> > We've sent fdmap(2) back in the day:
> Well, if the main point of the exercise is performance, then fdmap()
> is clearly inferior.
> Sadly, with all the HW security mitigation, system calls are no longer cheap.
> Would there ever be any other reason to traverse unknown open files
> than to close them?

I have had lively discussions and interestingly worded mails on account
of all of this. But noone has brought up this scenario. Florian also
said that it's not needed [1].

If we really want something like that we don't really need a new syscall
I think. We can just do a prctl() command or fcntl() command that will
give you back the next open fd.

There's imho crazy ideas out there what people expect a multi-close file
descriptor solution to look like. Service manager people apparently
think it would be a great idea to have a syscall that takes an array of
fds which the kernel is supposed to leave open and close all others,
basically "close all of the fds only leave out those I tell you".
I think for such a use-cases they can push for a prctl(PR_GET_NEXTFD, 2)
or a fcntl(2, F_GET_NEXTFD) and implement that in userspace.

I really only care about having a performant solution to closing a range
of fds that's a little more flexible than closefrom() without going all
crazy generic and copying (possibly) large bits of data between kernel-
and userspace.

close_range() is really something I've picked up on the side because the
current state has bothered me (and others) a long time whenever I have
to have my userspace hat on. With Al being in favor of it this seemed
like we should do it.
I actually wanted to have Jann's and my clone6() version on the table by
now since that would unblock larger things like the time namespace

In any case I'll send v3 with my max()/min() braino fixed that Oleg
thankfully spotted and the split into two patches that Arnd suggested.


  reply	other threads:[~2019-05-24 10:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 18:21 Alexey Dobriyan
2019-05-23 21:34 ` Linus Torvalds
2019-05-24 10:27   ` Christian Brauner [this message]
2019-05-24 18:39   ` Alexey Dobriyan
2019-05-24 18:55     ` Linus Torvalds
2019-05-24 21:27       ` Alexey Dobriyan
2019-05-24 23:45         ` Al Viro
  -- strict thread matches above, loose matches on Subject: below --
2019-05-23 15:47 Christian Brauner

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 0/2] close_range()' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).