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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29403 invoked from network); 21 Nov 2022 20:36:04 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 21 Nov 2022 20:36:04 -0000 Received: (qmail 5961 invoked by uid 550); 21 Nov 2022 20:35:24 -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 5916 invoked from network); 21 Nov 2022 20:35:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1669062867; bh=Ugt9k4CD3UAsZ8XBlHYI6eaEwXEFe/DyTRRLJObL+pY=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=lhc3RmICLl62vECTCQ/dP3aeJmgXyjNIePg+Hhj79/+LTx1KCGD8INVcQgn2klvgP ibBDWusRpmRjlkP85qGZgJ3EV24wMTzhgAbf2HMVjftWli/YnJmJTSaY+vMRqWKta3 c4OMkhTPxVi+zmhtkI8+JefLU7RNdgqLBMZmXdzAEnmlSgAV3Lna6Uz9TJoVhT3YBk TFNSTijoI4HBcwa0gfG9sJjN2D2aeWHm8Y+JMgBQlhrebMIncZoZMzH+eRn2JtpaxL s+W7ilhSprNC5grJ2gFA/vOi9PL+XVG4GRhsOu4FKZETncYMSjp8oh0rVE63KsXMiM el3Ru5g++K2Ng== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Mon, 21 Nov 2022 21:34:26 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20221121203426.GB2497@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:OGDGbjQanSJX/gJXXZ+vb1anj21KdnwG7xZqblVbVi+D/mIyqtE xMn690x1YgVdX0RuosqPX8W9HkIRHyaeqq9PfNLESSWTiKD+LQbGgeP78etV7J4hvBHSfDf cwXfEsO16bUtrtXWzUpQVeRIadK0DlfkER7mcUnC4owjRILxTMsHzNcvvofXkq8N11/dlTN C35Be1IUruOd+yHV2yXTA== UI-OutboundReport: notjunk:1;M01:P0:dLyoDDfE2kM=;cbhzQY/QaIEJuZnnzohVwpUuO6c /OCaUI7f0gpX6bqw427dxVuAotkgq0qqL2Kjpgk4GiQgLf9kKldjiA876+bf7UTmiYoZ2xYlv AcmbxpY31vvZJrpqrhvQe8kHR3QAuqWfD+QNvFW1AN6EmlP8nv7c7GM4r9VE1qeySUKcVzSP8 cStqavdfy77GxHTPPS749aUaN335ebI0tykhLrV9pbMvQOYl50ZKZ56ZGSA98boLyAQ1I930u LrtNyEp57tV2Z+DzP0lYasUG2O0gasG6HJ6OHvwQ5oKmKWAP/uoAVdfiyPxUH1zNqb8K+auMJ I6Zz5FcnJMzpNGycW9iNtop0dp07soVCTuZmTSVPD9/zT/6fBxDELs0wwyyWgxJWJLepU2FTg U9zVhWq9ck7BlRgRcjTaWKPwZMb730NynrormH0NeMb9puIql7e/ZTrnKOcA2unRMh95S24Vd TKjlvdJY/oRxjXVGca62TYwOkdzMyTNw2VkpzYNkeLVzDrt91YAqqxgxrEWtnHmpBjs8IZbPl UDgrfBy9U/xxxa07oKQ/aiHFzWNUC/FHhI1pLwaDtj/04/DFQ7+Q7qJz+qzusPLRnzQFWgeNA yPvt0m0PAjzEgIIq/r86hZXJ5EYFKs3XdjZ9DUFYQeC3A9cQt9txvy/FUlKtjnMI14xiOds7J 59HhlJXt0k+WfZty5y3sGauVUOjxiCYlQ0taMP4SHmKTVSFxGi120IXltKBslU6Dc0Ir1/PDJ rOWZqWX+xq2q0vutGlyHiCfzbJQxd0UZNB9LRZ+v3FWgaj7yDd8guznCEqtEPPZrNb2PRe8jQ /Nw7lj4XOoMp3c7UVallQWzVubPJV7slMlY2c5eo4fjoC16UYHpw6QDLBzOJquWz2ejKIuqbS T8BdCzoM3JiBV0Eq00h45PfZPb0/3svh0GsSDgAEJwjnX/NzxcNb5id5syVA+E7wHrDTcYeM5 /wQunA== Subject: Re: [musl] about sysconf(_SC_NPROCESSORS_CONF) issue On Mon, Nov 21, 2022 at 04:51:49PM +0800, =E5=85=94=E5=AD=90=E7=8C=AA wrot= e: > Hi > > > currently, we use "sysconf(_SC_NPROCESSORS_CONF)" to get the number of > the CPU,  and the musl implements this function by > SYS_sched_getaffinity system call,  when some of CPUs are > isolated, the return value is not correct. > Define "correct". That is actually the problem. See below. > > I have searched the history maillist of musl and found the same > issue: https://www.openwall.com/lists/musl/2021/05/05/,  but > there is no final conclusion. I wonder why musl is doing this? > The problem is that the definition of that value is rather lacking. Nobody really knows what the value is supposed to be, or what it could be used for. At least for sysconf(_SC_NPROCESSORS_ONLN), we have a rough idea, even though no conforming program could really tell the difference between running on 16 processors and running on 1 processor. But _CONF? _CONF could conceivably be the number of processors in the system, but that is unstable under CPU hotplug. So maybe the maximum number of processors the system can support? Or else the maximum number of processors the kernel can support? The smaller of both? What about disabled cores, do they count? And what would the value be used for? We found one program that uses the value to get kernel CPU IDs, and found that to be a bad use. That program should just have read /proc/cpuinfo itself, then it could also have coped with non-contiguous CPU IDs. Other than that, we could find no use of that value where the value returned by musl was really wrong. HTH, Markus