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 1048 invoked from network); 12 Jul 2021 18:12:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Jul 2021 18:12:17 -0000 Received: (qmail 5457 invoked by uid 550); 12 Jul 2021 18:12:15 -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 5438 invoked from network); 12 Jul 2021 18:12:14 -0000 Date: Mon, 12 Jul 2021 19:12:10 +0100 From: Vincent Donnefort To: Rich Felker Cc: Samuel Holland , musl@lists.openwall.com, jason Message-ID: <20210712181210.GA147578@e124901.cambridge.arm.com> References: <20210710053157.4F16D22215EC@gateway02.insomnia247.nl> <20210710194450.GX13220@brightrain.aerifal.cx> <20210712130840.GA47550@e120877-lin.cambridge.arm.com> <20210712154134.GY13220@brightrain.aerifal.cx> <20210712163246.GA115682@e124901.cambridge.arm.com> <20210712171454.GZ13220@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210712171454.GZ13220@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support [...] > > > If they're mandated stable interfaces that "happen" to have the exact > > > data we need, I don't see what the objection to using them is. A > > > better question would be whether access to them is restricted in any > > > hardening profiles. At least they don't seem to be hidden by the > > > hidepid mount option. > > > > Indeed the function hasn't changed for 10y, which is I guess somewhat stable > > and it is currently walking through all the possible CPUs (which is what we want > > to count). Also, this file is currently always present whenever procfs is > > mounted. > > > > Nonetheless, as this is human-readable, nothing mandates the format. And as an > > example, on my desktop machine, with 448 allocated CPUS, the first line of > > /proc/softirqs (the line that contains all the CPUs) is 4949 long. The > > "possible" mask describes same information with only 6 characters. > > It's not just a matter of age and de facto stability. Kernel policy is > that the procfs files are stable interfaces. Despite being "human > readable", they're also intended to be readable by, and actually read > by, utilities such as the procps suite of tools, "top"-type programs, > etc. > What I wanted to emphasis is the cost of reading that interface vs the CPU mask in the sysfs. The only gain is for a system with a _CONF user, where some CPUs have been hotunplug'ed, and where the sysfs isn't mounted while the procfs is. This can surely happen, but compared with the cost of parsing a long string (see the ~x1000 in the example above) it doesn't seem a good trade-off to me.