From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14025 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mathieu Desnoyers Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Date: Tue, 26 Mar 2019 14:01:08 -0400 (EDT) Message-ID: <1391784430.9599.1553623268878.JavaMail.zimbra@efficios.com> References: <20190315210202.GD6994@joraj-alpa> <20190316022534.GN26605@port70.net> <20190326162334.GF17481@joraj-alpa> <20190326174540.GH26605@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103501"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl , Michael Jeanson , Richard Purdie , Jonathan Rajotte To: Szabolcs Nagy Original-X-From: musl-return-14041-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 26 19:01:28 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h8qO5-000Qhx-CP for gllmg-musl@m.gmane.org; Tue, 26 Mar 2019 19:01:26 +0100 Original-Received: (qmail 13845 invoked by uid 550); 26 Mar 2019 18:01:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13824 invoked from network); 26 Mar 2019 18:01:21 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 1794C1CE20F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1553623269; bh=L3wTMrOxTe1WuCLu2UM8UUhSDBBEreYx0aFtIfNkemQ=; h=Date:From:To:Message-ID:MIME-Version; b=PtnRQPEQLlCni3xC6vsuRsP2HPXgpbt8G9uUT/k/Jn+iEKenZQ6h2mpJYqKUdi9TQ Qk0giXDR5RNmhdDzu0wd2ugPUkUwA86zby3RjgqMYxXfYLXS1jthvao4NhjdhxJcET F7uDb3fAZeJgRiVB/172IYdX+BZPeweFEAexkxpPaSVYFz3GC0kQZGtE9mtio8ST0D IjkgLgaEkTUM6gPJJ96M7+0C+7lR/h3zNHMQZZsp0mlYF1sztmOy9ncHN52IRRk30x IcfY0k6D9XAxdSEyZFnmjzOIib6nfqqbt+R7Q/NAABwnKfTvBB+Xl+HftUF0MtMdvO iFAxD7ULv7BUg== X-Virus-Scanned: amavisd-new at efficios.com In-Reply-To: <20190326174540.GH26605@port70.net> X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.11_GA_3780 (ZimbraWebClient - FF65 (Linux)/8.8.11_GA_3787) Thread-Topic: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Thread-Index: axCiFbpE91ACOMb1wkrMyeQXdwga8w== Xref: news.gmane.org gmane.linux.lib.musl.general:14025 Archived-At: ----- On Mar 26, 2019, at 1:45 PM, Szabolcs Nagy nsz@port70.net wrote: > * Jonathan Rajotte-Julien [2019-03-26 > 12:23:34 -0400]: >> > i think we need to know why does a process care if musl returns >> > the wrong number? or what are the valid uses of such a number? >> > (there are heterogeous systems like arm big-little, numa systems >> > with many sockets, containers, virtualization,.. how deep may a >> > user process need to go down in this rabbit hole?) >> >> Does the answers from Mathieu Desnoyers [1] and Florian Weimer [2] fit the bill? > > yes > >> >> [1] https://www.openwall.com/lists/musl/2019/03/16/3 >> [2] https://www.openwall.com/lists/musl/2019/03/19/1 >> > >> > note that most of /sys/devices/system/cpu/* is documented under >> > Documentation/ABI/testing in linux, not in Documentation/ABI/stable >> > and the format is not detailed, and some apis (e.g. /proc/cpuinfo) >> > are known to be different on android (and grsec?) kernels it may >> > be unmounted during early boot or in chroots, so sysfs parsing is >> > only done when really necessary. >> >> For what it's worth, uclibc and uclibc-ng seem to iterate over >> /sys/devices/system/cpu/* and fallback on online calculation if necessary. >> >> https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/unistd/sysconf.c#n102 >> >> In the mean time, we implemented a fallback similar to this when we do not >> "know" >> the libc used (since musl does not come with __musl__, I read the reasons why, >> no need to discuss this). >> >> Not sure of the direction musl should take but I strongly believe that the >> behaviour regarding _SC_NPROCESSORS_CONF is not the appropriate one. > > i agree that the current behaviour is not ideal, but > iterating over /sys/devices/system/cpu/cpu* may not > be correct either.. based on current linux api docs. > > i don't understand why is that number different from the > cpu set in /sys/devices/system/cpu/possible I suspect both iteration over /sys/devices/system/cpu/cpu* and content of /sys/devices/system/cpu/possible should provide the same result. However, looking at Linux Documentation/ABI/testing/sysfs-devices-system-cpu , it appears that /sys/devices/system/cpu/possible was introduced in December 2008, whereas /sys/devices/system/cpu/cpu#/ was there pre-git history. This could explain why glibc uses the iteration method. Thoughts ? Thanks, Mathieu > > it seems any upper bound on the number of cpus would be > valid but it's not clear how to provide that guarantee. -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com