All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	x86@kernel.org, Nadia Heninger <nadiah@cs.ucsd.edu>,
	Thomas Ristenpart <ristenpart@cornell.edu>,
	Theodore Ts'o <tytso@mit.edu>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Subject: Re: [PATCH RFC v1] random: implement getrandom() in vDSO
Date: Sat, 30 Jul 2022 00:06:26 +0200	[thread overview]
Message-ID: <YuRZ4tC+GY+hymFd@zx2c4.com> (raw)
In-Reply-To: <87a68r4qpy.fsf@oldenburg.str.redhat.com>

Hey Florian,

Thanks for the feedback.

On Fri, Jul 29, 2022 at 10:19:05PM +0200, Florian Weimer wrote:
> > +	if (getcpu(&start, NULL, NULL) == 0)
> > +		start %= NUM_BUCKETS;
> 
> getcpu is not available everywhere.  Userspace/libc should probably
> provide a CPU number hint as an additional argument during the vDSO
> call.  We can load that easily enough from rseq.  That's going to be
> faster on x86, too (the LSL instruction is quite slow).  The only
> advantage of using getcpu like this is that it's compatible with a libc
> that isn't rseq-enabled.

Actually, the only requirement is that it's somewhat stable and somehow
separates threads most of the time. So a per-thread ID or even a
per-thread address would work fine too. Adhemerval suggested on IRC this
afternoon that there's a thread pointer register value that would be
usable for this purpose. I think what I'll do for v2 is abstract this
out to a __arch_get_bucket_hint() function, or similar, which the
different archs can fill in.

> > +	for (i = start;;) {
> > +		struct getrandom_state *state = &buckets[i];
> > +
> > +		if (cmpxchg(&state->in_use, false, true) == false)
> > +			return state;
> > +
> > +		i = i == NUM_BUCKETS - 1 ? 0 : i + 1;
> > +		if (i == start)
> > +			break;
> > +	}
> 
> Surely this scales very badly once the number of buckets is smaller than
> the system processor count?

Right, and there are a few ways that observation can go:

1) It doesn't matter, because who has > 28 threads all churning at once
   here? Is that something real?

2) The state variable is controllable by userspace, so in theory
   different ones could be passed. I don't like this idea though - hard
   to manage and not enough information to do it well.

3) Since we know when this kind of contention is hit, it should be
   possible to just expand the map size. Seems a bit complicated.

4) Simply allocate a number of pages relative to the number of CPUs, so
   that this isn't actually a problem. This seems like the simplest
   approach and seems fine.

Jason 

  reply	other threads:[~2022-07-29 22:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29 14:55 [PATCH RFC v1] random: implement getrandom() in vDSO Jason A. Donenfeld
2022-07-29 20:19 ` Florian Weimer
2022-07-29 22:06   ` Jason A. Donenfeld [this message]
2022-07-30 15:48 ` Linus Torvalds
2022-07-30 23:45   ` Jason A. Donenfeld
2022-07-31  0:23     ` Jason A. Donenfeld
2022-07-31  1:31       ` [PATCH RFC v2] " Jason A. Donenfeld
2022-08-01  8:48         ` Florian Weimer
2022-08-01 12:49           ` Jason A. Donenfeld
2022-08-01 13:29             ` Jason A. Donenfeld
2022-08-01 13:00         ` Jason A. Donenfeld
2022-08-01 20:48         ` Thomas Gleixner
2022-08-01 23:41           ` Jason A. Donenfeld
2022-08-02  0:12             ` Jason A. Donenfeld
2022-08-01 19:30     ` [PATCH RFC v1] " Thomas Gleixner
2022-08-01 23:16       ` Jason A. Donenfeld
2022-08-02 13:46         ` Thomas Gleixner
2022-08-02 13:59           ` Jason A. Donenfeld
2022-08-02 15:14             ` Thomas Gleixner
2022-08-02 15:26               ` Jason A. Donenfeld
2022-08-02 22:27                 ` Thomas Gleixner
2022-08-04 15:23                   ` Jason A. Donenfeld
2022-08-04 16:08                     ` Jeffrey Walton
2022-08-04 23:11                     ` Thomas Gleixner
2022-08-17  8:20                   ` Peter Zijlstra
2022-08-05  8:36               ` Florian Weimer

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=YuRZ4tC+GY+hymFd@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nadiah@cs.ucsd.edu \
    --cc=ristenpart@cornell.edu \
    --cc=tytso@mit.edu \
    --cc=vincenzo.frascino@arm.com \
    --cc=x86@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.