]> git.baikalelectronics.ru Git - kernel.git/commit
drivers/char/random.c: fix priming of last_data
authorJarod Wilson <jarod@redhat.com>
Fri, 24 May 2013 22:55:31 +0000 (15:55 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 24 May 2013 23:22:52 +0000 (16:22 -0700)
commita4d1b939e63183eaa3f926a98843f9cd9cde0d1c
tree181e088925c447edbe88e05095effbcdfb71da4c
parent9d706ffbbd5b26224cfa61859f0382494d13e007
drivers/char/random.c: fix priming of last_data

Commit 7d710a23fa78 ("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>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drivers/char/random.c