]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
drivers/char/random.c: fix priming of last_data
authorJarod Wilson <jarod@redhat.com>
Thu, 9 May 2013 23:57:06 +0000 (09:57 +1000)
committerStephen Rothwell <sfr@canb.auug.org.au>
Tue, 21 May 2013 04:17:36 +0000 (14:17 +1000)
commit03d05d5b31a894103b6deb1e888b5f34739a9f21
tree2ac5cf28b4d68a24573b5590b4954ea0b5aa0ebb
parenta5fd8c4b71b0dfe083d00d0ee0621946335078c4
drivers/char/random.c: fix priming of last_data

Commit ec8f02da9e ("random: prime last_data value per fips requirements")
added priming of last_data per fips requirements.  Unfortuantely, it did
so in a way that can lead to multiple threads all incrementing nbytes, but
only one actually doing anything with the extra data, which leads to some
fun random corruption and panics.

The fix is to simply do everything needed to prime last_data in a single
shot, so there's no window for multiple cpus to increment nbytes -- in
fact, we won't even increment or decrement nbytes anymore, we'll just
extract the needed EXTRACT_SIZE one time per pool and then carry on with
the normal routine.

All these changes have been tested across multiple hosts and architectures
where panics were previously encoutered.  The code changes are are
strictly limited to areas only touched when when booted in fips mode.

This change should also go into 3.8-stable, to make the myriads of fips
users on 3.8.x happy.

Signed-off-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stodola <jstodola@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Matt Mackall <mpm@selenic.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drivers/char/random.c