Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Jun 2017 02:39:40 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: "Theodore Ts'o" <tytso@....edu>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, kernel-hardening@...ts.openwall.com, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Eric Biggers <ebiggers3@...il.com>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, David Miller <davem@...emloft.net>, 
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
> I wouldn't just push the lock one up as is but move that write part to
> crng_init to remain within the locked section. Like that:

We can't quite do that, because invalidate_batched_entropy() needs to
be called _before_ crng_init. Otherwise a concurrent call to
get_random_u32/u64() will have crng_init being the wrong value when
the batched entropy is still old.

> Are use about that? I am not sure that the gcc will inline "crng_init"
> read twice. It is not a local variable. READ_ONCE() is usually used
> where gcc could cache a memory access but you do not want this. But hey!
> If someone knows better I am here to learn.

The whole purpose is that I _want_ it to cache the memory access so
that it is _not_ inlined. So, based on your understanding, it does
exactly what I intended it to do. The reason is that I'd like to avoid
a lock imbalance, which could happen if the read is inlined.

Jason

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.