[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260917214423.GM23438@brightrain.aerifal.cx>
Date: Thu, 17 Sep 2026 17:44:24 -0400
From: Rich Felker <dalias@...c.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: Demi Marie Obenour <demiobenour@...il.com>, musl@...ts.openwall.com,
Jonas Böttiger <jonasboettiger@...oud.com>,
AWilcox@...cox-tech.com
Subject: Re: vDSO-based getrandom
On Wed, Sep 16, 2026 at 05:23:00PM +0200, Jason A. Donenfeld wrote:
> On Sun, Aug 23, 2026 at 11:44 PM Rich Felker <dalias@...c.org> wrote:
> >
> > On Sun, Aug 23, 2026 at 03:12:39PM -0600, Jason A. Donenfeld wrote:
> > > On Sun, Aug 23, 2026, 13:53 Rich Felker <dalias@...c.org> wrote:
> > > > On Sun, Aug 23, 2026 at 03:03:43PM -0400, Demi Marie Obenour wrote:
> > > > > I agree that this would be simpler, but I’m concerned that it could
> > > > > (a) be racy and (b) be a scalability bottleneck. I suspect the vDSO
> > > > > doesn’t guarantee that the atomics used have strong enough memory
> > > > > barriers for multithreaded use. Furthermore, modern server systems
> > > > > can have a very large number of cores and a global lock could be a
> > > > > serious scalability bottleneck.
> > > >
> > > > The strength of the atomics is a good question. If the ones used
> > > > internally are not sufficient you could do the same thing around it
> > > > with full strength atomics.
> > > >
> > > > I don't think allocating an extra page of memory per thread is very
> > > > nice.
> > > >
> > >
> > > It's not a page per thread. You allocate a page (or pages) and divide it
> > > between threads.
> >
> > Thanks for clarifying. So I guess you need to maintain some sort of
> > allocator state for which slots are used/free? Or one could try to
> > make it work with selecting a slot based on getcpu instead of
> > statically assigning them to threads.
>
> Yea. There's some demo code that's a lot simpler than the glibc stuff,
> that you could adapt, or at least read to get a more straight forward
> idea of how this is supposed to work.
> (Sorry for the delay; I've been traveling.)
>
> Voila: https://git.zx2c4.com/linux-rng/tree/tools/testing/selftests/vDSO/vdso_test_getrandom.c
A strategy that might be compatible with simplicity and
non-resource-hogging:
- Before some threshold of getrandom calls is reached, only use the
syscall. There is no justification for adding an entire page of
waste to processes that don't use getrandom or that only make some
small number of calls.
- Allocate one page of state and divide it up into however many (N)
slots fit into one page.
- Use slot vdso_getcpu()%N under trylock locking, probably with
fallback to syscall on contention (which should only happen on huge
numbers of cores or on rare migrations between cores racing with the
getcpu).
Is it possible to intersperse the locks with the opaque data blobs?
That would be nice.
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.
