LKML Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Alexey Dobriyan <>
Cc: Christian Brauner <>,
	Linux List Kernel Mailing <>,
	linux-fsdevel <>
Subject: Re: [PATCH v2 0/2] close_range()
Date: Fri, 24 May 2019 11:55:44 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20190524183903.GB2658@avx2>

On Fri, May 24, 2019 at 11:39 AM Alexey Dobriyan <> wrote:
> > Would there ever be any other reason to traverse unknown open files
> > than to close them?
> This is what lsof(1) does:

I repeat: Would there ever be any other reason to traverse unknown
open files than to close them?

lsof is not AT ALL a relevant argument.

lsof fundamentally wants /proc, because lsof looks at *other*
processes. That has absolutely zero to do with fdmap. lsof does *not*
want fdmap at all. It wants "list other processes files". Which is
very much what /proc is all about.

So your argument that "fdmap is more generic" is bogus.

fdmap is entirely pointless unless you can show a real and relevant
(to performance) use of it.

When you would *possibly* have a "let me get a list of all the file
descriptors I have open, because I didn't track them myself"
situation?  That makes no sense. Particularly from a performance

In contrast, "close_range()" makes sense as an operation. I can
explain exactly when it would be used, and I can easily see a
situation where "I've opened a ton of files, now I want to release
them" is a valid model of operation. And it's a valid optimization to
do a bulk operation like that.

IOW, close_range() makes sense as an operation even if you could just
say "ok, I know exactly what files I have open". But it also makes
sense as an operation for the case of "I don't even care what files I
have open, I just want to close them".

In contrast, the "I have opened a ton of files, and I don't even know
what the hell I did, so can you list them for me" makes no sense.

Because outside of "close them", there's no bulk operation that makes
sense on random file handles that you don't know what they are. Unless
you iterate over them and do the stat thing or whatever to figure it
out - which is lsof, but as mentioned, it's about *other* peoples


  reply	other threads:[~2019-05-24 18:56 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
2019-05-24 18:39   ` Alexey Dobriyan
2019-05-24 18:55     ` Linus Torvalds [this message]
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 \
    --in-reply-to='' \ \ \ \ \ \
    --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).