From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Stephen Kitt <steve@sk2.org>,
linux-man@vger.kernel.org,
Michael Kerrisk <mtk.manpages@gmail.com>,
linux-kernel@vger.kernel.org
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: <0ea38a7a-1c64-086e-3d64-38686f5b7856@gmail.com> (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‐
nal(7).
EIO An I/O error occurred.
ENOSPC, EDQUOT
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().
Thanks,
Alex
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; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es
next prev parent 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:
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=0ea38a7a-1c64-086e-3d64-38686f5b7856@gmail.com \
--to=alx.manpages@gmail.com \
--cc=christian.brauner@ubuntu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=steve@sk2.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.