Messages in this thread | | | Subject | Re: [patch] close_range.2: new page documenting close_range(2) | From | "Alejandro Colomar (man-pages)" <> | Date | Thu, 10 Dec 2020 15:36:42 +0100 |
| |
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
| |