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.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11412 invoked from network); 12 Oct 2023 17:43:26 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 12 Oct 2023 17:43:26 -0000 Received: (qmail 8183 invoked by uid 550); 12 Oct 2023 17:43:23 -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 8143 invoked from network); 12 Oct 2023 17:43:22 -0000 Date: Thu, 12 Oct 2023 13:43:18 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20231012174318.GK4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] aio_close needed in dup2? 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). 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