Re: [PATCH] random: publish crng_init with release semantics

[Jason A. Donenfeld]

Hi Jaidev,

On Mon, Sep 21, 2026 at 09:26:21PM -0400, Jaidev Shastri via B4 Relay wrote:
> From: Jaidev Shastri <jaidevshastri@xxxxxx>
> 
> crng_reseed() writes the new base key and bumps base_crng.generation
> under base_crng.lock, then sets crng_init to CRNG_READY with a plain
> store. crng_ready() reads crng_init with a plain load and without the
> lock, on the get_random_u8(), u16(), u32() and u64() fast paths and in
> crng_make_state().
> 
> Set the state with smp_store_release() and read it with
> smp_load_acquire(), so that a reader observing CRNG_READY also observes
> the key and the generation written before it. crng_ready() becomes a
> static inline function so that the acquire can carry its comment.
> 
> Found with MBCheck, a static herd7-based memory consistency checker.

It's "intentionally" like this actually. By that, I mean that I thought
about it when writing it and decided against it. But maybe my analysis
is silly. Here's the thinking:

crng_init only ever becomes CRNG_READY. It never goes from a ready state
to an unready state. And it becomes ready at a quasi "random" time. So
all the code around it is used to various things happening in a
potentially unready state. Once it's ready, however, it never becomes
unready.

So if it changes to ready, but the cores don't see the change for, say 5
whole seconds (several orders of magnitude longer than what's
realistic), then that's fine. They will _eventually_ see that it's
ready, in the same way that the rng itself _eventually_ becomes ready.
So I didn't think it was necessary for the cores to see that it's ready
at exactly the moment that it is ready and not a second after.

In other words, the consequences of this racing are basically nothing.

Does this make sense? If I've overlooked something, please do let me
know.

Thanks,
Jason