random: add 8-bit and 16-bit batches
Subsystems (2)
Jason A. Donenfeld
maintainerPATCH 1/1 random: add 8-bit and 16-bit batches
There are numerous places in the kernel that would be sped up by having smaller batches. Currently those callsites do get_random_u32() & 0xff or similar. Since these are pretty spread out, and will require patches to multiple different trees, let's get ahead of the curve and lay the foundation for get_random_u8() and get_random_u16(), so that it's then possible to start submitting conversion patches leisurely.
--- drivers/char/random.c | 2 ++ include/linux/random.h | 2 ++ 2 files changed, 4 insertions(+)
drivers/char/random.c +2 -0
@@ -506,6 +506,8 @@ EXPORT_SYMBOL(get_random_ ##type); DEFINE_BATCHED_ENTROPY(u64) DEFINE_BATCHED_ENTROPY(u32) +DEFINE_BATCHED_ENTROPY(u16) +DEFINE_BATCHED_ENTROPY(u8)#ifdef CONFIG_SMP /*
include/linux/random.h +2 -0
@@ -38,6 +38,8 @@ static inline int unregister_random_vmfork_notifier(struct notifier_block *nb) {#endif void get_random_bytes (void *buf,size_t len); +u8 get_random_u8 (void ); +u16 get_random_u16 (void );u32 get_random_u32 (void );u64 get_random_u64 (void );static inline unsigned int get_random_int (void )
Signature · 1 line
2.37.3
include/linux/random.h static inline int unregister_random_vmfork_notifier(struct notifier_block *nb) { · line 45
Quoted 10 lines · Jason A. Donenfeld
There are numerous places in the kernel that would be sped up by having smaller batches. ...
void
get_random_bytes(void *buf, size_t len);include/linux/random.h +2
-0+u8 get_random_u8 (void ); +u16 get_random_u16 (void );u32 get_random_u32 (void );u64 get_random_u64 (void );static inline unsigned int get_random_int (void )
To me, the 32-bit & 64-bit functions look like an obviously good idea. However, I cannot see that the 8-bit or 16-bit functions are needed.
Even library functions like getchar() return an int & whatever you return, it is going to be handled as an int-sized item if it goes in a register, so what's the point?
From: Sandy Harris
Quoted 18 lines
Sent: 25 November 2022 04:11
include/linux/random.h static inline int unregister_random_vmfork_notifier(struct notifier_block *nb) { · line 45
Quoted 10 lines · Jason A. Donenfeld
There are numerous places in the kernel that would be sped up by having smaller batches. ...
void
get_random_bytes(void *buf, size_t len);include/linux/random.h +2
-0+u8 get_random_u8 (void ); +u16 get_random_u16 (void );u32 get_random_u32 (void );u64 get_random_u64 (void );static inline unsigned int get_random_int (void )To me, the 32-bit & 64-bit functions look like an obviously good idea. However, I cannot see that the 8-bit or 16-bit functions are needed.
Quoted 4 lines
Even library functions like
getchar()return an int & whatever you return, it is going to be handled as an int-sized item if it goes in a register, so what's the point?
They avoid 'using up' random values the callers wont use. This can save expensive re-hashing (etc).
OTOH the return types should probably be u32 even though the domain is smaller.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)