search for: hwrng_unregister

From: Rusty Russell <rusty at rustcorp.com.au> 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. v4: add cleanup_done flag to insure that cleanup is done Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/core.c | 8 ++++++++ include/linux/hw_random.h | 1 + 2 files changed, 9 insertions(+)...

From: Rusty Russell <rusty at rustcorp.com.au> 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. v4: add cleanup_done flag to insure that cleanup is done Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/core.c | 8 ++++++++ include/linux/hw_random.h | 1 + 2 files changed, 9 insertions(+)...

...ll also enable us to remove the workaround added previously to > check whether probe was completed, and only then ask for data from the > host. The revert follows in the next commit. > > There's a slight behaviour change here on unsuccessful hwrng_register(). > Previously, when hwrng_unregister() failed, the probe() routine would > fail, and the vqs would be torn down, and driver would be marked not > initialized. Now, the vqs will remain initialized, driver would be > marked initialized as well, but won't be available in the list of RNGs > available to hwrng core. To fi...

...ll also enable us to remove the workaround added previously to > check whether probe was completed, and only then ask for data from the > host. The revert follows in the next commit. > > There's a slight behaviour change here on unsuccessful hwrng_register(). > Previously, when hwrng_unregister() failed, the probe() routine would > fail, and the vqs would be torn down, and driver would be marked not > initialized. Now, the vqs will remain initialized, driver would be > marked initialized as well, but won't be available in the list of RNGs > available to hwrng core. To fi...

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 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 insertions(+) > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index dc9092a1075d..b4a21e9521cf 100...

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 insertions(+) > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index dc9092a1075d..b4a21e9521cf 100...

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

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

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 insertions(+) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index dc9092a1075d..b4a21e9521cf 100644 --- a/drivers/char/hw_random/core.c...

Amos Kong <akong at redhat.com> writes: > From: Rusty Russell <rusty at rustcorp.com.au> > > 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. > > v4: add cleanup_done flag to insure that cleanup is done That's a bit weird. The usual pattern would be to hold a reference until we're actually finished, but this reference is a bit weird. We hold the mutex across cleanup, so we could grab that but we have to take care s...

On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > 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> You totally corrupted Rusty's patch. If you're going to repost his series you better make sure that you've got the right patches. Just as well though as it made me think a little more about this patch :)...

On Thu, Sep 18, 2014 at 08:37:45PM +0800, Amos Kong wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > 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> You totally corrupted Rusty's patch. If you're going to repost his series you better make sure that you've got the right patches. Just as well though as it made me think a little more about this patch :)...

...ce that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the host. The revert follows in the next commit. There's a slight behaviour change here on unsuccessful hwrng_register(). Previously, when hwrng_unregister() failed, the probe() routine would fail, and the vqs would be torn down, and driver would be marked not initialized. Now, the vqs will remain initialized, driver would be marked initialized as well, but won't be available in the list of RNGs available to hwrng core. To fix the failures, the...

...08:37:45PM +0800, Amos Kong wrote: > >> From: Rusty Russell <rusty at rustcorp.com.au> > >> > >> 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> > > > > You totally corrupted Rusty's patch. If you're going to repost > > his series you better make sure that you've got the right patches. > > > > Just as w...

...08:37:45PM +0800, Amos Kong wrote: > >> From: Rusty Russell <rusty at rustcorp.com.au> > >> > >> 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> > > > > You totally corrupted Rusty's patch. If you're going to repost > > his series you better make sure that you've got the right patches. > > > > Just as w...

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