From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, PDS_RDNS_DYNAMIC_FP,RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7BC531F8C6 for ; Wed, 7 Jul 2021 12:52:07 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8521A3951C4C for ; Wed, 7 Jul 2021 12:52:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8521A3951C4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1625662326; bh=prQ9TeVxbB4sjSJUMwXkOgr9uYefJ5SyT3/5UjM4hW4=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=KJKhnJClU12I1sNNuu2ZFhwKIE4rLR/TaJqiXsvit8hGVqv5KcihIXu6sK21mrQ7L /seVIas/8nMatYjlSEW2GczYDSTtusjfKKtfVgn9rh25PY4Hqzz7VwYkgPYKtC910b lCqDbR9DP7hYGJVCsCINS7ML8IxtIpwP8cfPXKks= Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 54E523857434 for ; Wed, 7 Jul 2021 12:51:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54E523857434 Received: by mail-pj1-x102e.google.com with SMTP id x21-20020a17090aa395b029016e25313bfcso1577507pjp.2 for ; Wed, 07 Jul 2021 05:51:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=prQ9TeVxbB4sjSJUMwXkOgr9uYefJ5SyT3/5UjM4hW4=; b=pQOJflKry/HvMah9SDI+CfpwRMyTJWn+Qps3hHTbGdNKebViInLN0kcMGJafv6FUu0 ttfkCSBRe3v8m/EIwYYpDcYZSktPTTeDFpAM+iw735r3YbF3pb5cW4CfCiV1tlLXFlvo s8Wjcqi21MQKKd9baEXNSkTSq4ID2US/P6/n/aMVpNe5DtknhsPU3f5mrQ4jtzicXk/M geG1ckRv0VaepGgkP2RYYTOpmIEva+uE/JNg5YQm6te/hv1dy/t/5WdGcF6XJLq/anEE OY1ein+kjv9qv4mkw+j9Bosc47MkmD0G2yEoj6iOiEDSpXiuEfuAiAvxJs15pqj89WI/ ntKw== X-Gm-Message-State: AOAM530REulSCoH4YF5rwdKWEUC05cuSDLiADx7yzOHSqBVPbuKHuAu7 6yT+ZVGYa+N/ZfWL8Mdhy2mDLpfzPFhSfg== X-Google-Smtp-Source: ABdhPJzP5dIQUuHmk2Qy8bAe6a5RYjyGLBGxTtZ9Wl7XGH25exOZqks41l/pAaSTd6zzguXZ3W2m9g== X-Received: by 2002:a17:90b:a0c:: with SMTP id gg12mr25229329pjb.138.1625662304985; Wed, 07 Jul 2021 05:51:44 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id t14sm21064487pfe.45.2021.07.07.05.51.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 05:51:44 -0700 (PDT) Subject: Re: [PATCH v7 2/4] linux: Add close_range To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <20210706145839.1658623-1-adhemerval.zanella@linaro.org> <20210706145839.1658623-3-adhemerval.zanella@linaro.org> <87fswqa0eo.fsf@oldenburg.str.redhat.com> Message-ID: <9c726db9-9744-8030-a708-02454b8ecd26@linaro.org> Date: Wed, 7 Jul 2021 09:51:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87fswqa0eo.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" 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 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). */