From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id A488B3858C2C for ; Mon, 8 Nov 2021 14:55:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A488B3858C2C Received: by mail-oi1-x231.google.com with SMTP id q124so27959561oig.3 for ; Mon, 08 Nov 2021 06:55:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=wSYp5p2ZyivIX2dVYCU7aGkQe6z7ttnCb05ADGFVfy8=; b=ahMzrj5+3+wpg+HWaMLwdBwM4TxFTjhrYAXxkY1E4uiOii6IxPRGn+qKHRQcYVuUrz 6VHdtkFY3UpLzHxPkEqptJfts+HSZnQKfKWVA2o8oucUDDJDbN55q6z3pi0Z2a8x7OLi GVQp7tDPvOAhFvzhvjwTla4CC1/A5PTSXuaE0eVN9mL2qvJyDa23h4zQBAmDQeJaNty7 mWGioZcd0BaRWV0QnqGWcnd27wnFzqmAJp3XWDa6nbpHA9VPMR8ZdafHODliq3Benlvr lNDcqt4zFeXBm86wtH2Ee+jFVUfks52Syk9T0mTUjW3oWBYTDaleTfqijzWW5zJRRDL/ hrGg== X-Gm-Message-State: AOAM531N7lU/q9zcDJuqkP47oCgJTxoe8L3X1uQXU3vz6cvitJboLRIZ dmemMgXnDauhRnW3EO1tRY2BCA== X-Google-Smtp-Source: ABdhPJxuj0bSVoXSz9BSWi+6Bce1Q7Omv6ZIYu+Yr/VaNSDGBQlz1GsYoX0n8DCgZJfGER7dPz6pOw== X-Received: by 2002:aca:c6d0:: with SMTP id w199mr17517729oif.30.1636383357068; Mon, 08 Nov 2021 06:55:57 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:c067:29b:4c08:be99? ([2804:431:c7cb:55a:c067:29b:4c08:be99]) by smtp.gmail.com with ESMTPSA id u132sm5927167oib.50.2021.11.08.06.55.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 06:55:56 -0800 (PST) Message-ID: <2485e81c-157e-37c5-317b-6f16fae8f211@linaro.org> Date: Mon, 8 Nov 2021 11:55:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH] io: Refactor close_range and closefrom Content-Language: en-US To: Sergey Bugaev Cc: libc-alpha@sourceware.org, Samuel Thibault References: <20211108135800.2189664-1-adhemerval.zanella@linaro.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 08 Nov 2021 14:56:02 -0000 On 08/11/2021 11:13, Sergey Bugaev wrote: > Hello, > > I hope it's appropriate for me to leave some comments on the patch... > > On Mon, Nov 8, 2021 at 4:58 PM Adhemerval Zanella > wrote: >> +#if __ASSUME_CLOSE_RANGE >> +static inline _Bool __closefrom_fallback (int __lowfd, _Bool dirfd_fallback) >> +{ >> + return true; >> +} > > My understanding is that this will get called if we assume close_range > is available, but it still somehow fails. Should it maybe return false > in this case, to cause closefrom to fail/abort, rather than silently > succeeding? Indeed it makes sense to return false and force the __fortify_fail() on the generic implementation. > >> +stub_warning (close_range) > > Wouldn't this warn that "close_range is not implemented and will > always fail"? I'd expect that warning for a stub that always fails > with ENOSYS, but not for a working (if non-atomic etc) implementation. Yeah, this does not make sense. I will remove it. > >> --- a/posix/unistd.h >> +++ b/posix/unistd.h >> @@ -1199,6 +1199,17 @@ int getentropy (void *__buffer, size_t __length) __wur >> __attr_access ((__write_only__, 1, 2)); >> #endif >> >> +#ifdef __USE_GNU >> +/* 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 this (either closes everything or nothing) an appropriate thing to > promise in the common header? Similarly, if the default implementation > accepts no flags, should the common description mention "the > CLOSE_RANGE prefix"? Well, that's the semantic of the both the syscall and the Linux fallback. If Hurd does not provide such semantic I think you should work this out. For CLOSE_RANGE I think it does make sense because it is not setting any support flag, but rather the way it might be provided by the system.