kernel/linux.git/drivers/char/hw_random, branch v4.4.235

x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping

2020-06-11T07:21:40+00:00

commit b399151cb48db30ad1e0e93dd40d68c6d007b637 upstream. x86_mask is a confusing name which is hard to associate with the processor's stepping. Additionally, correct an indent issue in lib/cpu.c. [ Backport by Mark Gross to simplify the SRBDS backport ] Signed-off-by: Jia Zhang [ Updated it to more recent kernels. ] Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bp@alien8.de Cc: tony.luck@intel.com Link: http://lkml.kernel.org/r/1514771530-70829-1-git-send-email-qianyue.zj@alibaba-inc.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

hwrng: exynos - Disable runtime PM on driver unbind

2020-05-10T08:26:32+00:00

commit 27d80fa8bccf8d28bef4f89709638efc624fef9a upstream. Driver enabled runtime PM but did not revert this on removal. Re-binding of a device triggered warning: exynos-rng 10830400.rng: Unbalanced pm_runtime_enable! Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled

2020-01-04T12:34:09+00:00

[ Upstream commit eaecce12f5f0d2c35d278e41e1bc4522393861ab ] When unloading omap3-rom-rng, we'll get the following: WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable This is because the clock may be already disabled by omap3_rom_rng_idle(). Let's fix the issue by checking for rng_idle on exit. Cc: Aaro Koskinen Cc: Adam Ford Cc: Pali Rohár Cc: Sebastian Reichel Cc: Tero Kristo Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support") Signed-off-by: Tony Lindgren Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

hwrng: stm32 - fix unbalanced pm_runtime_enable

2019-12-05T14:27:18+00:00

commit af0d4442dd6813de6e77309063beb064fa8e89ae upstream. No remove function implemented yet in the driver. Without remove function, the pm_runtime implementation complains when removing and probing again the driver. Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman

hwrng: core - don't wait on add_early_randomness()

2019-10-05T10:27:55+00:00

commit 78887832e76541f77169a24ac238fccb51059b63 upstream. add_early_randomness() is called by hwrng_register() when the hardware is added. If this hardware and its module are present at boot, and if there is no data available the boot hangs until data are available and can't be interrupted. For instance, in the case of virtio-rng, in some cases the host can be not able to provide enough entropy for all the guests. We can have two easy ways to reproduce the problem but they rely on misconfiguration of the hypervisor or the egd daemon: - if virtio-rng device is configured to connect to the egd daemon of the host but when the virtio-rng driver asks for data the daemon is not connected, - if virtio-rng device is configured to connect to the egd daemon of the host but the egd daemon doesn't provide data. The guest kernel will hang at boot until the virtio-rng driver provides enough data. To avoid that, call rng_get_data() in non-blocking mode (wait=0) from add_early_randomness(). Signed-off-by: Laurent Vivier Fixes: d9e797261933 ("hwrng: add randomness to system from rng...") Cc: Reviewed-by: Theodore Ts'o Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

hwrng: virtio - Avoid repeated init of completion

2019-04-27T07:33:52+00:00

[ Upstream commit aef027db48da56b6f25d0e54c07c8401ada6ce21 ] The virtio-rng driver uses a completion called have_data to wait for a virtio read to be fulfilled by the hypervisor. The completion is reset before placing a buffer on the virtio queue and completed by the virtio callback once data has been written into the buffer. Prior to this commit, the driver called init_completion on this completion both during probe as well as when registering virtio buffers as part of a hwrng read operation. The second of these init_completion calls should instead be reinit_completion because the have_data completion has already been inited by probe. As described in Documentation/scheduler/completion.txt, "Calling init_completion() twice on the same completion object is most likely a bug". This bug was present in the initial implementation of virtio-rng in f7f510ec1957 ("virtio: An entropy device, as suggested by hpa"). Back then the have_data completion was a single static completion rather than a member of one of potentially multiple virtrng_info structs as implemented later by 08e53fbdb85c ("virtio-rng: support multiple virtio-rng devices"). The original driver incorrectly used init_completion rather than INIT_COMPLETION to reset have_data during read. Tested by running `head -c48 /dev/random | hexdump` within crosvm, the Chrome OS virtual machine monitor, and confirming that the virtio-rng driver successfully produces random bytes from the host. Signed-off-by: David Tolnay Tested-by: David Tolnay Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

x86/cpufeature: Remove unused and seldomly used cpu_has_xx macros

2018-06-16T07:54:24+00:00

commit 362f924b64ba0f4be2ee0cb697690c33d40be721 upstream. Those are stupid and code should use static_cpu_has_safe() or boot_cpu_has() instead. Kill the least used and unused ones. The remaining ones need more careful inspection before a conversion can happen. On the TODO. Signed-off-by: Borislav Petkov Link: http://lkml.kernel.org/r/1449481182-27541-4-git-send-email-bp@alien8.de Cc: David Sterba Cc: Herbert Xu Cc: Peter Zijlstra Cc: Matt Mackall Cc: Chris Mason Cc: Josef Bacik Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

hwrng: stm32 - add reset during probe

2018-05-30T05:49:14+00:00

[ Upstream commit 326ed382256475aa4b8b7eae8a2f60689fd25e78 ] Avoid issue when probing the RNG without reset if bad status has been detected previously Signed-off-by: Lionel Debieve Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

hwrng: exynos - use __maybe_unused to hide pm functions

2018-02-25T10:03:47+00:00

commit b93f342da1766ef1740e6277508329356c4ea48b upstream. The exynos random driver uses #ifdef to check for CONFIG_PM, but then uses SIMPLE_DEV_PM_OPS, which leaves the references out when CONFIG_PM_SLEEP is not defined, so we get a warning with PM=y && PM_SLEEP=n: drivers/char/hw_random/exynos-rng.c:166:12: error: 'exynos_rng_suspend' defined but not used [-Werror=unused-function] drivers/char/hw_random/exynos-rng.c:171:12: error: 'exynos_rng_resume' defined but not used [-Werror=unused-function] This removes the incorrect #ifdef and instead uses a __maybe_unused annotation to let the compiler know it can silently drop the function definition. Signed-off-by: Arnd Bergmann Reviewed-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

hwrng: core - sleep interruptible in read

2018-01-17T08:35:28+00:00

commit 1ab87298cb59b649d8d648d25dc15b36ab865f5a upstream. hwrng kthread can be waiting via hwrng_fillfn for some data from a rng like virtio-rng: hwrng D ffff880093e17798 0 382 2 0x00000000 ... Call Trace: [] wait_for_completion_killable+0x96/0x210 [] virtio_read+0x57/0xf0 [virtio_rng] [] hwrng_fillfn+0x75/0x130 [] kthread+0xf3/0x110 And when some user program tries to read the /dev node in this state, we get: rngd D ffff880093e17798 0 762 1 0x00000004 ... Call Trace: [] mutex_lock_nested+0x15c/0x3e0 [] rng_dev_read+0x6e/0x240 [] __vfs_read+0x28/0xe0 [] vfs_read+0x83/0x130 And this is indeed unkillable. So use mutex_lock_interruptible instead of mutex_lock in rng_dev_read and exit immediatelly when interrupted. And possibly return already read data, if any (as POSIX allows). v2: use ERESTARTSYS instead of EINTR Signed-off-by: Jiri Slaby Cc: Matt Mackall Cc: Herbert Xu Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman