On Tue, Dec 13, 2022 at 12:35:24AM +0200, Amit Klein wrote: > On Mon, Dec 12, 2022 at 8:03 PM Yonghong Song <yhs@xxxxxxxx> wrote: > > > > > > > > On 12/11/22 2:16 PM, david.keisarschm@xxxxxxxxxxxxxxx wrote: > > > From: David <david.keisarschm@xxxxxxxxxxxxxxx> > > > > > > We changed the invocation of > > > prandom_u32_state to get_random_u32. > > > We deleted the maintained state, > > > which was a CPU-variable, > > > since get_random_u32 maintains its own CPU-variable. > > > We also deleted the state initializer, > > > since it is not needed anymore. > > > > > > Signed-off-by: David <david.keisarschm@xxxxxxxxxxxxxxx> > > > --- > > > include/linux/bpf.h | 1 - > > > kernel/bpf/core.c | 13 +------------ > > > kernel/bpf/verifier.c | 2 -- > > > net/core/filter.c | 1 - > > > 4 files changed, 1 insertion(+), 16 deletions(-) > > > > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h > [...] > > Please see the discussion here. > > https://lore.kernel.org/bpf/87edtctz8t.fsf@xxxxxxx/ > > There is a performance concern with the above change. > > > > I see. How about using (in this instance only!) the SipHash-based > solution which was the basis for prandom_u32() starting with commit > c51f8f88d705 (v5.10-rc1) up until commit d4150779e60f (v5.19-rc1)? Stop with this pseudo cryptographic garbage. Stop pushing this everywhere. It was a hassle to undo this crap the first time around. The last thing we need is to add it back. Plus, there's no need for it either. I'll revisit the bpf patch if/when it makes sense to do performance-wise. Jason
