From cc7ecfff4ee63164da3b6f42bac0a47a341d4b0e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 29 Jul 2014 11:06:49 -0700 Subject: [PATCH] 3.15-stable patches added patches: hwrng-virtio-ensure-reads-happen-after-successful-probe.patch --- ...-reads-happen-after-successful-probe.patch | 78 +++++++++++++++++++ queue-3.15/series | 1 + 2 files changed, 79 insertions(+) create mode 100644 queue-3.15/hwrng-virtio-ensure-reads-happen-after-successful-probe.patch diff --git a/queue-3.15/hwrng-virtio-ensure-reads-happen-after-successful-probe.patch b/queue-3.15/hwrng-virtio-ensure-reads-happen-after-successful-probe.patch new file mode 100644 index 00000000000..4bdd63c59b9 --- /dev/null +++ b/queue-3.15/hwrng-virtio-ensure-reads-happen-after-successful-probe.patch @@ -0,0 +1,78 @@ +From e052dbf554610e2104c5a7518c4d8374bed701bb Mon Sep 17 00:00:00 2001 +From: Amit Shah +Date: Thu, 10 Jul 2014 15:42:35 +0530 +Subject: hwrng: virtio - ensure reads happen after successful probe + +From: Amit Shah + +commit e052dbf554610e2104c5a7518c4d8374bed701bb upstream. + +The hwrng core asks for random data in the hwrng_register() call itself +from commit d9e7972619. This doesn't play well with virtio -- the +DRIVER_OK bit is only set by virtio core on a successful probe, and +we're not yet out of our probe routine when this call is made. This +causes the host to not acknowledge any requests we put in the virtqueue, +and the insmod or kernel boot process just waits for data to arrive from +the host, which never happens. + +CC: Kees Cook +CC: Jason Cooper +CC: Herbert Xu +Reviewed-by: Jason Cooper +Signed-off-by: Amit Shah +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/hw_random/core.c | 6 ++++++ + drivers/char/hw_random/virtio-rng.c | 10 ++++++++++ + 2 files changed, 16 insertions(+) + +--- a/drivers/char/hw_random/core.c ++++ b/drivers/char/hw_random/core.c +@@ -68,6 +68,12 @@ static void add_early_randomness(struct + unsigned char bytes[16]; + int bytes_read; + ++ /* ++ * Currently only virtio-rng cannot return data during device ++ * probe, and that's handled in virtio-rng.c itself. If there ++ * are more such devices, this call to rng_get_data can be ++ * made conditional here instead of doing it per-device. ++ */ + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); + if (bytes_read > 0) + add_device_randomness(bytes, bytes_read); +--- a/drivers/char/hw_random/virtio-rng.c ++++ b/drivers/char/hw_random/virtio-rng.c +@@ -30,6 +30,8 @@ static unsigned int data_avail; + static DECLARE_COMPLETION(have_data); + static bool busy; + ++static bool probe_done; ++ + static void random_recv_done(struct virtqueue *vq) + { + /* We can get spurious callbacks, e.g. shared IRQs + virtio_pci. */ +@@ -56,6 +58,13 @@ static int virtio_read(struct hwrng *rng + { + int ret; + ++ /* ++ * Don't ask host for data till we're setup. This call can ++ * happen during hwrng_register(), after commit d9e7972619. ++ */ ++ if (unlikely(!probe_done)) ++ return 0; ++ + if (!busy) { + busy = true; + init_completion(&have_data); +@@ -110,6 +119,7 @@ static int probe_common(struct virtio_de + return err; + } + ++ probe_done = true; + return 0; + } + diff --git a/queue-3.15/series b/queue-3.15/series index 0b3ba094e97..e3e52179294 100644 --- a/queue-3.15/series +++ b/queue-3.15/series @@ -31,3 +31,4 @@ drm-radeon-fix-irq-ring-buffer-overflow-handling.patch drm-radeon-fix-cut-and-paste-issue-for-hawaii.patch mm-hugetlb-fix-copy_hugetlb_page_range.patch fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch +hwrng-virtio-ensure-reads-happen-after-successful-probe.patch -- 2.47.3