On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote:
> There's a bigger problem here, which is that cifs_lock_secret is a
> 32-bit value which is being used to obscure flock->fl_owner before it
> is sent across the wire. But flock->fl_owner is a pointer to the
> struct file *, so 64-bit architect
On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote:
> There's a bigger problem here, which is that cifs_lock_secret is a
> 32-bit value which is being used to obscure flock->fl_owner before it
> is sent across the wire. But flock->fl_owner is a pointer to the
> struct file *, so 64-bit architect
On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote:
> Using get_random_u32 here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is sometimes when this is used.
>
> Signed-
Using get_random_u32 here is faster, more fitting of the use case, and
just as cryptographically secure. It also has the benefit of providing
better randomness at early boot, which is sometimes when this is used.
Signed-off-by: Jason A. Donenfeld
Cc: Steve French
---
fs/cifs/cifsfs.c | 2 +-
1
