On Thu, Jun 8, 2017 at 2:50 AM, Jason A. Donenfeld wrote:
> On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o wrote:
>> I'm guessing you changed key_alloc_serial() to return an int back when
>> you were thinking that you might use get_random_bytes_wait(), which
>> could return -ERESTARTSYS.
>>
>> Now
On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o wrote:
> I'm guessing you changed key_alloc_serial() to return an int back when
> you were thinking that you might use get_random_bytes_wait(), which
> could return -ERESTARTSYS.
>
> Now that you're not doing this, but using get_random_u32() instead,
>
On Tue, Jun 06, 2017 at 07:47:55PM +0200, Jason A. Donenfeld wrote:
> -static inline void key_alloc_serial(struct key *key)
> +static inline int key_alloc_serial(struct key *key)
> @@ -170,7 +168,7 @@ static inline void key_alloc_serial(struct key *key)
> rb_insert_color(&key->serial_node, &
Otherwise, we might use bad random numbers which, particularly in the
case of IV generation, could be quite bad. It makes sense to use the
synchronous API here, because we're always in process context (as the
code is littered with GFP_KERNEL and the like). However, we can't change
to using a blocki