archive mirror
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <>
To: Christian Brauner <>
Cc: Stephen Kitt <>,,
	Michael Kerrisk <>,
Subject: Re: [patch] close_range.2: new page documenting close_range(2)
Date: Thu, 10 Dec 2020 15:36:42 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20201209105618.okw5lgcdikg5bvae@wittgenstein>

Hi Christian,

Thanks for confirming that behavior.  Seems reasonable.

I was wondering...
If this call is equivalent to unshare(2)+{close(2) in a loop},
shouldn't it fail for the same reasons those syscalls can fail?

What about the following errors?:

From unshare(2):

       EPERM  The calling process did not have the  required  privi‐
              leges for this operation.

From close(2):
       EBADF  fd isn't a valid open file descriptor.

OK, this one can't happen with the current code.
Let's say there are fds 1 to 10, and you call 'close_range(20,30,0)'.
It's a no-op (although it will still unshare if the flag is set).
But souldn't it fail with EBADF?

       EINTR  The close() call was interrupted by a signal; see sig‐

       EIO    An I/O error occurred.

              On NFS, these errors are not normally reported against
              the first write which exceeds  the  available  storage
              space,  but  instead  against  a  subsequent write(2),
              fsync(2), or close().



On 12/9/20 11:56 AM, Christian Brauner wrote:
> On Wed, Dec 09, 2020 at 11:44:22AM +0100, Alejandro Colomar (man-pages) wrote:
>> Hey Christian,
>> I have a question for you below.
>> Thanks,
> Hey Alex,
> Sure!


>> AFAICS after reading the code, if the unsharing fails,
>> it will not close any file descriptors (please correct me if I'm wrong).
>> Just wanted to be sure that it was the intended behavior with you,
>> and if so, it would be good to document it in the page.
> Yes, this is intended because if the unshare fails we haven't yet
> actually started closing anything so we're before the point of no
> return where we ignore failures. So we can let userspace decide whether
> they want to retry without CLOSE_RANGE_UNSHARE.
> Christian

Alejandro Colomar
Linux man-pages comaintainer;

  reply	other threads:[~2020-12-10 16:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 21:51 [patch] close_range.2: new page documenting close_range(2) Stephen Kitt
2020-12-09  8:50 ` Michael Kerrisk (man-pages)
2020-12-09  9:40   ` Christian Brauner
2020-12-09  9:43     ` Stephen Kitt
2020-12-09  9:47   ` Alejandro Colomar (man-pages)
2020-12-10 22:40     ` Michael Kerrisk (man-pages)
2020-12-09  9:58 ` Christian Brauner
2020-12-09 10:44   ` Alejandro Colomar (man-pages)
2020-12-09 10:56     ` Christian Brauner
2020-12-10 14:36       ` Alejandro Colomar (man-pages) [this message]
2020-12-12 12:14         ` Christian Brauner
2020-12-12 17:58           ` Alejandro Colomar (man-pages)
2020-12-18 10:12             ` Ping: " Alejandro Colomar (man-pages)
2020-12-18 10:14               ` Stephen Kitt

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 \ \ \ \ \ \ \ \

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