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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	FREEMAIL_FROM,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 9189 invoked from network); 12 Oct 2023 16:43:38 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 12 Oct 2023 16:43:38 -0000
Received: (qmail 16078 invoked by uid 550); 12 Oct 2023 16:43:33 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 16040 invoked from network); 12 Oct 2023 16:43:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417;
 t=1697129001; x=1697733801; i=nullplan@gmx.net;
 bh=SllU4/Co/WNnsjtFIZHiI4F+LMr7WhLqT+kGR3v1BFw=;
 h=X-UI-Sender-Class:Date:From:To:Subject;
 b=qTxmMx6uKnqnBzgYOpnqRgEd0cVmOOQuIy6pvXTeKDFJc0GdRiuvPYwxNdyZte04hNJcgy5GfMN
 90zub5cD5fKMFhHVgJNTIMTak+X/Bh2PyWJLrWqVX0Kv93ORqglHR/BqzHJqIOWfzxXaAYOfD0u9h
 +7FV+E4U/gjBNGA7rFDZ5p8NF8GS1RdPy903wq03pbRWWcH5XLu32Xkq+94SwsZ88BUcVg8eYINZ5
 QkF7tGdkXnxYDWGcw4O3xHoMW621Ph17+B48zMsvKgQDU+e40X6NFEIxOIIJs+A4jpqYKuVSJzur7
 Phv3eJ3+0MctistaHnq7jtbq4xd5vJ+hJF+g==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Date: Thu, 12 Oct 2023 18:43:20 +0200
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Message-ID: <ZSgiKLka+j6StpEm@voyager>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Provags-ID: V03:K1:A+XJJZwKOh3nPT9pCX5GRRdIhWR9Pu/364S8dJFq91ZmUZcxePH
 Z8xmHPdqwMZKhTvXJystcW8kgMR1izv4yImO+Fa/20hd7CmY9DNtspGtt+E1+p8bUbTQ9U8
 gWLkeITmgcsYOWRzk3IYzxyZNUaWGVfgcWU3i5P732dAsiwSQ4lA/ONP4F39s68mfoxYy9U
 l1PZ1u+Fr8JsX2AxoC1oA==
UI-OutboundReport: notjunk:1;M01:P0:xzm7R4fFEBI=;MtSPUaPJJRXedkthrt507TYTMl6
 uztsqXkFE4P7kCVGwM70ZuvZ/WhWW+xpnwdZhFW7P6VQHmTQYyZVOpnxsS72yArzw5NEjvR4s
 HI2x4kWZI2NLEt2aFQ/SCbgPIbQpAzjZgGFwR3vlBMVAFEjAxEAnrn2CcM9RQpqELAPBqs4Xx
 sl7nEyB/UgvB++/bWvk2KgY0qRAq90gqrpIyyfQm3A2hLJF1TkrhjoVkvUfe034cPdn48FaJ2
 cEiqm/pIbyFypAZq6V/LLLeDqwF6cXiqTdKs41V85S4dAy4C6f45qxgf9aCr+2BtvngnCrw5O
 POcYkGU7iSy3kVy8UsGBk7DMK6t+Kpx9dOPVeNycO5pN6G0q6kCpjnVIpWeRvS2lYPVhG6bSm
 XP6EDs7hYouFDoRFVaRA2ibwczkuKhvrQvqGc+/I0dU7aaIDc6mSnBh/uSyJZODXA9KMWeR9Z
 8uhymm9bPZ7olYAMnANhaB3ig4/5dCqiu3In3JMxwMcx9/r2AlexPtVeddJ+7cTB46afSq+0m
 kgiK9SPrim2IJlRKfIWVYp/i7HiQUfEiXZCRR6hGHEnTJRYoJ/J4D+uKZXj6dt2GsDmkM5jx8
 0LWZvSifcLi/NkncTnZQZ3akosqxygA9g2GKGtmBv8okjRPfyMP9GvZalpn5sX3IX4yoic81e
 JwsKbEDkkvhdP6qNSPjOLMEaKRm6g1/lszZO4K3bXfG+PrvQzVRCf/i/lA+lBR+aUs5R8EGZJ
 Gy5ospfQVvPiyGEeBHvjx9YuSUFpUc038gXb46UfnLZvbmy7otpiWdeUthy8dWAETUqd0vGUY
 CkGfWf7X38XMfl76XUr0W0p2E597p3UnFA/S2rFEBUCCYvu/HjR6L/Bjv/04oOM7IV3Y/qDf0
 lKNCG+QhC4ersHO+KqxApaWoJpk6aKMzJyMVJrJ9l8li4qniCYhLdRo8lUD+3XbzUHMkIBccW
 a3F8Lw==
Subject: [musl] aio_close needed in dup2?

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()?

Ciao,
Markus