mailing list of musl libc
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Vincent Donnefort <vincent.donnefort@arm.com>
Cc: Samuel Holland <samuel@sholland.org>,
	musl@lists.openwall.com, jason <jason@insomnia247.nl>
Subject: Re: [musl] [PATCH v3] sysconf: add _SC_NPROCESSORS_CONF support
Date: Mon, 12 Jul 2021 11:41:35 -0400
Message-ID: <20210712154134.GY13220@brightrain.aerifal.cx> (raw)
In-Reply-To: <20210712130840.GA47550@e120877-lin.cambridge.arm.com>

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

  reply	other threads:[~2021-07-12 15:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10  5:31 jason
2021-07-10 17:11 ` Rich Felker
2021-07-10 17:29 ` Samuel Holland
2021-07-10 19:44   ` Rich Felker
2021-07-12 13:08     ` Vincent Donnefort
2021-07-12 15:41       ` Rich Felker [this message]
2021-07-12 16:32         ` Vincent Donnefort
2021-07-12 17:14           ` Rich Felker
2021-07-12 18:12             ` Vincent Donnefort
2021-08-07 14:52             ` James Y Knight
2021-08-07 16:29           ` Leah Neukirchen
  -- strict thread matches above, loose matches on Subject: below --
2021-07-06  9:55 Vincent Donnefort

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210712154134.GY13220@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=jason@insomnia247.nl \
    --cc=musl@lists.openwall.com \
    --cc=samuel@sholland.org \
    --cc=vincent.donnefort@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git