[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210712163246.GA115682@e124901.cambridge.arm.com>
Date: Mon, 12 Jul 2021 17:32:46 +0100
From: Vincent Donnefort <vincent.donnefort@....com>
To: Rich Felker <dalias@...c.org>
Cc: Samuel Holland <samuel@...lland.org>, musl@...ts.openwall.com,
jason <jason@...omnia247.nl>
Subject: Re: [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support
On Mon, Jul 12, 2021 at 11:41:35AM -0400, Rich Felker wrote:
> 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.
Sorry, I wasn't clear. No functional differences. What we're losing is a
simple interface: a CPU mask.
>
> > 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
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.
--
Vincent.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
