From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25970 invoked from network); 12 Oct 2023 23:40:51 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 12 Oct 2023 23:40:51 -0000 Received: (qmail 15650 invoked by uid 550); 12 Oct 2023 23:40:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15602 invoked from network); 12 Oct 2023 23:40:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697154034; x=1697758834; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=f9b4OaYgifsd824ElQLV0uM4VGo/UrSdrBsYUSuwf24=; b=jTmAJySu2UkiSuLD/MYmaHXthSaVSr2+aPcOG9snLLDWv4ww4OavT1rjVY8k2FABY0 3byuNWPs8wWOQymLLwwTW7x8IJ7Pk3/WbqjSp2FULM7qBQp8nTXcZl+53lALR6OhxkaW M5PWZTqX/J5EBNaRYm2BssPpYUSYZTAB0dC6P+d/m0BWgNalqPnxlcS8B6Tw9rfxQmjB qPRGUHKwDZzFQ54e8NqyLdHQpts8Rrq2B4dRNaYjic8G9fgg73vBgT7+BCeNtN0kVdmw +BXjSr1mHYSTSjaXHg+chyocCu43CP1FftZ4+DfpsHz+785uXe4Nv5VL/LMQrvtlylgP x3+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697154034; x=1697758834; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f9b4OaYgifsd824ElQLV0uM4VGo/UrSdrBsYUSuwf24=; b=q38XXXh8hZgvEF/e24jMLR0lr3sujCnGLqhBQjaJkaNu3B/hr0oWuYz0jp4lZCiNop PUPoX02RIOtxhbtuLq3sGCPZAwUqrVF92AnkTOSwxlRoOWTq8LwDGMm75OpwT5DvAu0c Aae8E6lhwrP9++OMTeu2S5/hjSaDBmIva3+x3hxu/jlc8wvX1/NZkpWL2e0/fcceyMn4 iJLt2TXOcNybOvQdp1LBLeRVw+9wD7CGCscU089Ti6YVsWrEz8j5Ahjf89DruEAgA0J/ zCs7g0Dy9a4xqYRl/HYsMyH2P7Cv/P7MZGWL7wS2kMDb9seoSEplm6xHbpj8V3i8fJsa MkRg== X-Gm-Message-State: AOJu0YzEp46dM5bcYZI9LgbhpxDQR8l+uc1PFfmEQO/AfgC8buXirUEd L+z9pm/8ywXJRIEv5CzRjiSuLk+f4ckorA== X-Google-Smtp-Source: AGHT+IH/cHMbd1xotkwgqJkTnPNdwkBPS8OqayFlbpe07bYcVtBJluKuAZ5FMtnLiZ/3clBemkbRgg== X-Received: by 2002:a1c:7218:0:b0:406:81e9:ad0c with SMTP id n24-20020a1c7218000000b0040681e9ad0cmr23328493wmc.41.1697154034269; Thu, 12 Oct 2023 16:40:34 -0700 (PDT) Message-ID: Date: Fri, 13 Oct 2023 00:40:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 To: musl@lists.openwall.com, Rich Felker , Markus Wichmann References: <20231012174318.GK4163@brightrain.aerifal.cx> Content-Language: en-US From: Gabriel Ravier In-Reply-To: <20231012174318.GK4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] aio_close needed in dup2? On 10/12/23 18:43, Rich Felker wrote: > On Thu, Oct 12, 2023 at 06:43:20PM +0200, Markus Wichmann wrote: >> Hi all, >> >> I noticed something today: In close(), we call __aio_close() to both >> prevent AIO from using invalid file descriptors and implement the >> requirement that outstanding AIO be cancelled. But in dup2() and dup3(), >> that doesn't happen. >> >> POSIX only says that dup2() closes newfd if it already is a valid file >> descriptor. While not explicitly stated, I can't really find a sensible >> interpretation of that requirement that is different from "as if by way >> of close()". POSIX has no concept of closing file descriptors in any >> other way. And dup3() is an extension function, but I think most >> programmers will understand it to be an extension of dup2(), so the same >> argument applies there. >> >> So, do we need to call __aio_close() in dup2() and dup3()? > I'm not sure. Unlike close, which invalidates the fd and makes any > subsequent use by aio a use-after-close bug (extremely dangerous), > dup2/dup3 does not invalidate the fd. They change what it refers to. > While I'm not sure this is sanctioned by POSIX, it would be reasonable > to want to *atomically replace* an fd that aio is pending on, such > that the operations happen either on the previously-referenced open > file description or the new one (but never zero or both). I can confirm that current POSIX wants dup2 to be atomic: > All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2008 when they operate on regular files or symbolic links: > [list that includes many functions operating on file descriptors, including dup2] - POSIX-1.2008, 2.9.7 *Thread Interactions with Regular File Operations* The latest draft has similar wording which also includes dup3, in particular: > Except where specified otherwise, all of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-202x when they operate on file descriptors that are open, or being opened, to files in the file hierarchy: > [list that includes many functions operating on file descriptors, including dup2 and dup3] > If two threads each call one of these functions, each call shall either see all of the specified effects of the other call, or none of them. The requirement on the close() function shall also apply whenever a file descriptor is successfully closed, however caused (for example, as a consequence of calling close(), calling dup2(), or of process termination). - POSIX.1-202x with the specification of `close` including: > When there is an outstanding cancelable asynchronous I/O operation against fildes when close() is called, that I/O operation may be canceled. An I/O operation that is not canceled completes as if the close() operation had not yet occurred. All operations that are not canceled shall complete as if the close() blocked until the operations completed. The close() operation itself need not block awaiting such I/O completion. Whether any I/O operation is canceled, and which I/O operation may be canceled upon close(), is implementation-defined. - POSIX.1-202x and nothing in the specification of dup3 or dup2 indicating that they are not atomic. > > On the other hand, I don't see a safe way to implement __aio_close > semantics for dup2/dup3, because you can't know in advance whether > it's going to succeed, and once it succeeds, you can no longer do the > work __aio_close would have done. I think you'd have to juggle around > temporary fds to make it work in any reasonable way. > > Most likely, it's just supposed to be UB to replace an fd with pending > aio operations on it using dup2/dup3. (BTW, dup3 is not just an > extension, it's POSIX-future, so all this applies to it too.) > > Rich