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 16145 invoked from network); 12 Jul 2021 15:41:50 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Jul 2021 15:41:50 -0000 Received: (qmail 9663 invoked by uid 550); 12 Jul 2021 15:41:48 -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 9645 invoked from network); 12 Jul 2021 15:41:48 -0000 Date: Mon, 12 Jul 2021 11:41:35 -0400 From: Rich Felker To: Vincent Donnefort Cc: Samuel Holland , musl@lists.openwall.com, jason Message-ID: <20210712154134.GY13220@brightrain.aerifal.cx> References: <20210710053157.4F16D22215EC@gateway02.insomnia247.nl> <20210710194450.GX13220@brightrain.aerifal.cx> <20210712130840.GA47550@e120877-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210712130840.GA47550@e120877-lin.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support On Mon, Jul 12, 2021 at 02:08:42PM +0100, Vincent Donnefort wrote: > On Sat, Jul 10, 2021 at 03:44:50PM -0400, Rich Felker wrote: > > On Sat, Jul 10, 2021 at 12:29:34PM -0500, Samuel Holland wrote: > > > Hi all, > > > > > > While this topic is being discussed, I'd like to bring up another possible > > > method for consideration. It turns out that some files in procfs have contents > > > depending on the number of {possible,online} CPUs; we can parse them to get the > > > count we need. > > > > > > The benefits are: > > > - procfs is more likely to be mounted than sysfs, and it is already > > > documented as being required by musl. > > > - Some of the procfs interfaces have been around longer than the > > > sysfs interface. > > > - The parsing logic is somewhat simpler than for the files in > > > /sys/devices/system/cpu, because we are just counting the number > > > of occurrences of some string. > > > > > > The downsides are: > > > - It depends on the stability of the procfs file formats. > > > - The kernel uses more CPU to generate the contents of these files. > > > > My understanding is that the procfs files have stronger stability > > mandate than sysfs if anything (originally, only procfs was stable and > > sysfs was not). So I think it's perfectly acceptable to use and prefer > > procfs. And indeed it's more likely to be mounted; some > > container/sandbox setups I use bind-mount (or mount a new) procfs but > > do not expose any sysfs. > > Only to cover the case where a user needs _CONF and doesn't have the sysfs > mounted, which is very unlikely, we are losing a lot. Can you quantify what we're "losing"? As I understood the proposal, nothing at all is lost. > The masks, found in the > CPU subsystem are well documented, widely available, describe precisely the CPU > topology (which is what we want) and are "easy" to decode without fscanf. fscanf is not available here. The same can be done without it, if needed, though. > Moreover, in the case of a non-available sysfs, the fallback to sched_getaffinity > would help and at least align _CONF with _ONL (which is the current behavior). > > Reading /proc/stat and /proc/softirq looks like a hack. They just happen to > align on the _ONL/_CONF and doesn't produce a machine-readable output. While > the CPU sysfs subsys is really meant to describe CPUs. 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. Rich