I agree with Ted, this patch is just to start the discussion on how we can safely remove these locks for the improvement of safety and security. Both boot and interrupt benchmarks stand to benefit from a patch like this, so it is worth a deep dive. Feedback welcome, I am always looking for ways I can be a better engineer, and a better hacker and a better person. And we are all here to make the very best kernel. Regards, Micahel On Tue, Mar 29, 2022 at 8:39 AM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Mon, Mar 28, 2022 at 06:08:26PM +0000, Eric Biggers wrote: > > On Mon, Mar 28, 2022 at 07:18:00AM -0400, Sasha Levin wrote: > > > From: "Jason A. Donenfeld" <Jason@xxxxxxxxx> > > > > > > [ Upstream commit 6e8ec2552c7d13991148e551e3325a624d73fac6 ] > > > > > > > I don't think it's a good idea to start backporting random commits to random.c > > that weren't marked for stable. There were a lot of changes in v5.18, and > > sometimes they relate to each other in subtle ways, so the individual commits > > aren't necessarily safe to pick. > > > > IMO, you shouldn't backport any non-stable-Cc'ed commits to random.c unless > > Jason explicitly reviews the exact sequence of commits that you're backporting. > > Especially this commit in general, which is making a fundamental > change in how we extract entropy. We should be very careful about > taking such changes into stable; a release or two of additonal "soak" > time would be a good idea before these go into the LTS releases in particular. > > - Ted
