Re: [PATCH v2] ARM: initialize jump labels before setup_machine_fdt()

From: Jason A. Donenfeld
Date: Tue Jun 07 2022 - 06:11:34 EST


Hi Catalin,

On Tue, Jun 07, 2022 at 11:06:56AM +0100, Catalin Marinas wrote:
> Hi Jason,
>
> On Tue, Jun 07, 2022 at 10:51:41AM +0200, Jason A. Donenfeld wrote:
> > On Tue, Jun 7, 2022 at 10:47 AM Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote:
> > > Thanks for the quick response, but that doesn't work for me either. Let me say
> > > again that I'm on a downstream kernel (rpi-5.15.y) so this may not be a
> > > universal problem, but merging either of these fixing patches would be fatal for us.
> >
> > Alright, thanks. And I'm guessing you don't currently have a problem
> > *without* either of the fixing patches, because your device tree
> > doesn't use rng-seed. Is that right?
> >
> > In anycase, I sent in a revert to get all the static branch stuff out
> > of stable -- https://lore.kernel.org/stable/20220607084005.666059-1-Jason@xxxxxxxxx/
> > -- so the "urgency" of this should decrease and we can fix this as
> > normal during the 5.19 cycle.
>
> Since the above revert got queued in -stable, I assume you don't need
> commit 73e2d827a501 ("arm64: Initialize jump labels before
> setup_machine_fdt()") in stable either.

I made the point here:
https://lore.kernel.org/stable/Yp8i9DH57dRGfTNf@xxxxxxxxx/T/#m8f33bc14b677980abe690e5c7a4909b5902010cc

> Do you plan to fix the crng_ready() static branch differently? If you
> do, I'd like to revert the corresponding arm64 commit as well. It seems
> to be harmless but I'd rather not keep it if no longer needed. So please
> keep me updated whatever you decide.

I sent a "backup commit" for that here: https://lore.kernel.org/all/20220607100210.683136-1-Jason@xxxxxxxxx/
But I would like a few days to see if there's some trivial way of not
needing that on arm32. If it turns out to be easy, then I'd prefer the
direct fix akin to the arm64 one. If it turns out to be not easy, then
I'll merge the backup commit. I'll keep you posted (and I assume anyway
you'll see the arm32 attempts progress or fail here, also).

Jason