similar to: [PATCH v5 REPOST 0/6] fix hw_random stuck

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

Amos Kong <akong at redhat.com> writes: > I started a QEMU (non-smp) guest with one virtio-rng device, and read > random data from /dev/hwrng by dd: > > # dd if=/dev/hwrng of=/dev/null & > > In the same time, if I check hwrng attributes from sysfs by cat: > > # cat /sys/class/misc/hw_random/rng_* > > The cat process always gets stuck with slow backend (5

Amos Kong <akong at redhat.com> writes: > I started a QEMU (non-smp) guest with one virtio-rng device, and read > random data from /dev/hwrng by dd: > > # dd if=/dev/hwrng of=/dev/null & > > In the same time, if I check hwrng attributes from sysfs by cat: > > # cat /sys/class/misc/hw_random/rng_* > > The cat process always gets stuck with slow backend (5

There's currently a big lock around everything, and it means that we can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) while the rng is reading. This is a real problem when the rng is slow, or blocked (eg. virtio_rng with qemu's default /dev/random backend) This doesn't help (it leaves the current lock untouched), just adds a lock to protect the read function

On Thu, Sep 18, 2014 at 08:37:44PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > current_rng holds one reference, and we bump it every time we want > to do a read from it. > > This means we only hold the rng_mutex to grab or drop a reference, > so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't > block on read of

On Thu, Sep 18, 2014 at 08:37:44PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > current_rng holds one reference, and we bump it every time we want > to do a read from it. > > This means we only hold the rng_mutex to grab or drop a reference, > so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't > block on read of

On Thu, Sep 18, 2014 at 12:18:24PM +0930, Rusty Russell wrote: > The previous patch added one potential problem: we can still be > reading from a hwrng when it's unregistered. Add a wait for zero > in the hwrng_unregister path. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > --- > drivers/char/hw_random/core.c | 5 +++++ > 1 file changed, 5

On Thu, Sep 18, 2014 at 12:18:24PM +0930, Rusty Russell wrote: > The previous patch added one potential problem: we can still be > reading from a hwrng when it's unregistered. Add a wait for zero > in the hwrng_unregister path. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > --- > drivers/char/hw_random/core.c | 5 +++++ > 1 file changed, 5

A bit late to a party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is

A bit late to a party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > > > However, some rng