From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 9D9842C5C2 for ; Tue, 8 Oct 2024 17:26:38 +0200 (CEST) Received: (qmail 3086 invoked by uid 550); 8 Oct 2024 15:26:32 -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 x-ms-reactions: disallow Received: (qmail 2023 invoked from network); 8 Oct 2024 15:26:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1728401183; x=1729005983; i=nullplan@gmx.net; bh=oHRg2mbrwaW4zISXYUFOOHfP+gQr0uQDlVUDs9uXR0U=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=FUoGF4iCljDwNl1R0Lt2sdRZM+7qjli3WX4is280yzAkp4mtt6zyHGN6ddtuJb0P jyhCVVph7ZuNLpyTORp7GGKewl7AvwLIF5x50xXXGWgEIfQtr/o6S/CY1yoCtyQnh MNFo6XoFKLPeC1FVPGUK4PlH6uo2rza1r4JbkszQXSn16rkfeQCA0BjkHmiStj4iD Es8VOQvvxHFw9jxZ5rZ3f4242u5AYTL46Dm3fPDEovB6FOEz+KDzl8o4m7K7YKW1P T53PHoHOvUFvZ+8sIaAS9Nem9Hb8p+0HZ+Ane2yDDhr5X856jm+vMg4MQ7j1lMPBq /wiunH+1KH6hSlHv8w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Tue, 8 Oct 2024 17:26:22 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Provags-ID: V03:K1:pPyYiRXDpsuk127pCvYYWNlDAQcdoiNz/5r+xuqX7XvYhP5Fg6Y P35eBbb+MgLW9BDxmQozJR4VNhRNDHRtMofRQdmjR7A60mxCXBQAwdLGkzFe5nMmYIdisB/ vRUJL/jzvqfnV7kO3BEa+qk68eULmUs7T/Xc3zeiYZNkmoAK5wbq+0BX/f2VkV3rv7QObY4 mVxU2dHsGvKzeHgxkvVGw== UI-OutboundReport: notjunk:1;M01:P0:h2aZWDAMPck=;4Tf+xq/9LfiinU58gg2ObmDZxnw Pq1oUcmDilOKpgjoD71UMM1rORjZQ5LPmuLj4T8yxDt8MXmnlrWBHsb1cJ7NegalC41noL/+l AqaGw3qzSyv/AWNYh8GZ6KUuJP1MjQ71Rq4IcECUSIfvUA6mT/VHQ2Cy0yB9bN+UXCuI/U3JK J92po2M9d9F/jMw5OM+5/MIfiBjif/4bV+ZdcdmGFIxzDGioHFuCfRG9pBdxXvzZe0LZ/qTt7 8Drk7nqyBzqR68VhHpXr2+H9CtkyMP8F4jgFWPXLNjNQj9aK9W3Vm2CYQOqmF9TbhVuBBIZyy BwIsIzAOSTIGD03SmINvT/ZvcaIHKuxVJcRC37FpRSjB7njMf2xSOKqxsC/6F7sKLCIX9ZpXa /Rpj2ulUPUf4yY71LwS0M+/9VZ6nm60folFhYKvLSUtk2YkBdLzAH7C4DSqcqO/YQgNOdOEGe c94UGE/hi2tXvQlxxo9ckF/KWt1YvYpz/KM7p4tWLLmdKQICg0gfxwAk/F3IRoE8V6itUGiOP 8GUq3K/54c+7B2nd16wmw/58pJWqAaX5ChxjoRZk8ai3gxePxsPA7b6f/Jd2tQjtMhIxw3cVg rG8n1UOnz11qjMDgqZJRJRMcM8K3r6D3C8QYgjksXtbcDm6RJNMEMgZ0HKDIsTTBEDtxHgE0n gfFPpEhJliLtzvZzPsrNUCAmNjIsE/NAc6Ide1heqVrQj7GSgCQvWt+oiOCAQP34saPPS//I9 +XAqqMggbEbrepW+6/NtPistxaK1tL73pXW9ChFwC4K07U6Khac37J19vp8MnpkIyzdMl36C4 sriYnQMqA2TrRr3wkmGN54WA== Subject: [musl] pthread_getcpuclockid and POSIX Hi all, I am already sorry in advance that this is hardly going to contain constructive criticism, because at this point, I see a few problems and no real solutions. pthread_getcpuclockid() is a function that is supposed to return a clockid that can be passed to the clock_* and timer_* functions and references the CPU time of the thread identified by its handle. Currently, we simply return an encoding of the raw kernel TID. This means the clockid becomes invalid as soon as the thread terminates. Minor gripe: Isn't reading the TID from another thread's descriptor without holding the killlock a potential data race? Major gripe: If called on a zombie thread, this successfully returns a clockid that is equivalent to CLOCK_THREAD_CPUTIME_ID. glibc returns ESRCH in that case, which POSIX neither condones nor condemns. It says in an informative section that that should be returned for thread handles used after the end of life of a thread, but the definitions section in XSH explicitly includes the zombie phase in the thread lifetime. POSIX doesn't really say how long such a clockid should be valid, but I should think the life of the thread at least, and again, that includes the zombie phase. But our current implementation doesn't deliver that. If the clockid is retrieved after a thread becomes a zombie, then we return a valid clockid that doesn't do what the caller thinks it does, and if called before that, we return a clockid that might not work when used (if the thread exited between the calls to pthread_getcpuclockid() and clock_gettime()) or, worse, might refer to a completely different thread (if a new thread with the same TID was created). What can be done? If we could somehow encode the thread descriptor into the clock ID, then clock_gettime() could recognize those CPU times and do some special handling. For example, it could take the killlock on the thread and then perform the syscall only if the thread is still alive. pthread_exit() could store the final CPU time in the thread descriptor at the same time as it is clearing out the TID, and clock_gettime() could return that if the thread is no longer alive. Of course, all the other clock_* and timer_* functions would have to change as well. Alas, this can probably not be done, as clockid_t is defined to be an int, and we cannot define it to be larger without breaking ABI. Shoveling 64 pounds of stuff into a 32-pound bag has never worked before, so I don't think we can represent a pthread_t in a clockid_t. Let alone doing so in a way that preserves the static clocks already in use (and compiled into binary programs), and the dynamic process CPU time clocks clock_getcpuclockid() returns. I also struggle to find any users of this interface that aren't always calling it with the first argument set to pthread_self(). I did find OpenJDK, which calls it on its main thread. But otherwise, nothing. Ciao, Markus