[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210712154134.GY13220@brightrain.aerifal.cx>
Date: Mon, 12 Jul 2021 11:41:35 -0400
From: Rich Felker <dalias@...c.org>
To: Vincent Donnefort <vincent.donnefort@....com>
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 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
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.
