Re: [PATCH v7 2/4] linux: Add close_range

[Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>]

On 07/07/2021 07:22, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
> 
>> diff --git a/manual/llio.texi b/manual/llio.texi
>> index eafc27120d..ea6d34dd5a 100644
>> --- a/manual/llio.texi
>> +++ b/manual/llio.texi
>> @@ -284,6 +284,55 @@ of trying to close its underlying file descriptor with @code{close}.
>>  This flushes any buffered output and updates the stream object to
>>  indicate that it is closed.
>>  
>> +@deftypefun int close_range (unsigned int @var{lowfd}, unsigned int @var{maxfd}, int @var{flags})
>> +@standards{Linux, unistd.h}
>> +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
>> +@c This is a syscall for Linux v5.9.  There is no fallback emulation for
>> +@c older kernels.
>> +
>> +The function @code{close_range} closes the file descriptor from @var{lowfd}
>> +to @var{maxfd} (inclusive).  This function is similar to call @code{close} in
>> +specified file descriptor range depending on the @var{flags}.
>> +
>> +This is function is only supported on recent Linux versions and @theglibc{}
>> +does not provide any fallback (the application will need to handle possible
>> +@code{ENOSYS}).
>> +
>> +The @var{flags} add options on how the files are closes.  Linux currently
>> +supports:
>> +
>> +@vtable @code
>> +@item CLOSE_RANGE_UNSHARE
>> +Unshare the file descriptor table before closing file descriptors.
>> +
>> +@item CLOSE_RANGE_CLOEXEC
>> +Set the @code{FD_CLOEXEC} bit instead of closing the file descriptor.
>> +@end vtable
>> +
>> +The normal return value from @code{close_range} is @math{0}; a value
>> +of @math{-1} is returned in case of failure.  The following @code{errno} error
>> +conditions are defined for this function:
>> +
>> +@table @code
>> +@item EINVAL
>> +The @var{lowfd} value is larger than @var{maxfd} or an unsupported @var{flags}
>> +is used.
>> +
>> +@item ENOMEM
>> +Either there is not enough memory for the operation, or the process is
>> +out of address space.
> 
> I think the address space limitation does not apply here, and this error
> can only happen for CLOSE_RANGE_UNSHARE.  This is important information
> because plain close cannot fail, either.  No possibility of failure is a
> requirement in many cases to use this interface.

Yes, it seems that only CLOSE_RANGE_UNSHARED code patch (unshare_fd->dup_fd)
does trigger it.  I changed it to:

  @item EMFILE                                                                                                     
  The process has too many files open and it can only happens when                                                 
  @code{CLOSE_RANGE_UNSHARED} is used.                                                                             
  The maximum number of file descriptors is controlled by the                                                      
  @code{RLIMIT_NOFILE} resource limit; @pxref{Limits on Resources}.     

> 
>> +@item EMFILE
>> +The process has too many files open.
>> +The maximum number of file descriptors is controlled by the
>> +@code{RLIMIT_NOFILE} resource limit; @pxref{Limits on Resources}.
> 
> Can EMFILE (or ENFILE) really happen even with CLOSE_RANGE_UNSHARE?  I
> don't think so.

It is what man-pages describes:

  commit e3e22b2b2b50829191e93e05653fc3651171b8dc
  Author: Michael Kerrisk <mtk.manpages@gmail.com>
  Date:   Sun Mar 21 16:32:20 2021 +0100

      close_range.2: Correct the explanation of the EMFILE error
    
      close_range() CLOSE_RANGE_USHARE triggers a call to dup_fd()
      which in turn calls alloc_fdtable(), which checks that
      sysctl_nr_open has not been exceeded.
    
I also have change it to:

 @item ENOMEM                                                                                                     
 Either there is not enough memory for the operation, or the process is                                           
 out of address space.  It can only when @code{CLOSE_RANGE_UNSHARED} is
 used.


> 
>> diff --git a/sysdeps/unix/sysv/linux/bits/unistd_ext.h b/sysdeps/unix/sysv/linux/bits/unistd_ext.h
>> index 2e529be577..bf313e8af8 100644
>> --- a/sysdeps/unix/sysv/linux/bits/unistd_ext.h
>> +++ b/sysdeps/unix/sysv/linux/bits/unistd_ext.h
>> @@ -33,4 +33,26 @@
>>     not detached and has not been joined.  */
>>  extern __pid_t gettid (void) __THROW;
>>  
>> +#ifdef __has_include
>> +# if __has_include ("linux/close_range.h")
>> +#  include "linux/close_range.h"
>> +# endif
>>  #endif
>> +/* Unshare the file descriptor table before closing file descriptors.  */
>> +#ifndef CLOSE_RANGE_UNSHARE
>> +# define CLOSE_RANGE_UNSHARE (1U << 1)
>> +#endif
>> +/* Set the FD_CLOEXEC bit instead of closing the file descriptor.  */
>> +#ifndef CLOSE_RANGE_CLOEXEC
>> +# define CLOSE_RANGE_CLOEXEC (1U << 2)
>> +#endif
>> +
>> +/* Close all file descriptors in the range FD up to MAX_FD.  The flag FLAGS
>> +   are define by the CLOSE_RANGE prefix.  This function behaves like close
>> +   on the range, but in a fail-safe where it will either fail and not close
>> +   any file descriptor or close all of them.  Returns 0 on successor or -1
>> +   for failure (and sets errno accordingly).  */
>> +extern int close_range (unsigned int __fd, unsigned int __max_fd,
>> +			int __flags) __THROW;
> 
> The fail-safe aspect is not mentioned in the manual.  It's confused
> because it's unclear what happens with gaps.

I changed it to the following, since afaiu kernel ignores gaps and our
fallback also ignore close return code.

  /* Close all file descriptors in the range FD up to MAX_FD.  The flag FLAGS
     are define by the CLOSE_RANGE prefix.  This function behaves like close
     on the range, but in a fail-safe where it will either fail and not close
     any file descriptor or close all of them.  Gaps where the file descriptor
     is invalid are ignored.   Returns 0 on successor or -1 for failure (and
     sets errno accordingly).  */