search for: virtio_read

...opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call. > The reason is that virtio_read() always returns 0 in non-blocking mode, > even if data is available. Worse, it fetches random data from the > hypervisor after every non-blocking call, without ever using this data. > > The following test program illustrates the behavior and can be used > for testing and experiment...

...opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call. > The reason is that virtio_read() always returns 0 in non-blocking mode, > even if data is available. Worse, it fetches random data from the > hypervisor after every non-blocking call, without ever using this data. > > The following test program illustrates the behavior and can be used > for testing and experiment...

...uct scatterlist sg; sg_init_one(&sg, buf, size); /* There should always be room for one buffer. */ - virtqueue_add_inbuf(vq, &sg, 1, buf, GFP_KERNEL); + virtqueue_add_inbuf(vi->vq, &sg, 1, buf, GFP_KERNEL); - virtqueue_kick(vq); + virtqueue_kick(vi->vq); } static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) { int ret; + struct virtrng_info *vi = (struct virtrng_info *)rng->priv; - if (!busy) { - busy = true; - init_completion(&have_data); - register_buffer(buf, size); + if (!vi->busy) { + vi->busy = true; + init_completion(&a...

...uct scatterlist sg; sg_init_one(&sg, buf, size); /* There should always be room for one buffer. */ - virtqueue_add_inbuf(vq, &sg, 1, buf, GFP_KERNEL); + virtqueue_add_inbuf(vi->vq, &sg, 1, buf, GFP_KERNEL); - virtqueue_kick(vq); + virtqueue_kick(vi->vq); } static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) { int ret; + struct virtrng_info *vi = (struct virtrng_info *)rng->priv; - if (!busy) { - busy = true; - init_completion(&have_data); - register_buffer(buf, size); + if (!vi->busy) { + vi->busy = true; + init_completion(&a...

...gt;> b/drivers/char/hw_random/virtio-rng.c >>>>>> index 79a6e47b5fbc..984713b35892 100644 >>>>>> --- a/drivers/char/hw_random/virtio-rng.c >>>>>> +++ b/drivers/char/hw_random/virtio-rng.c >>>>>> @@ -59,6 +59,20 @@ static int virtio_read(struct hwrng *rng, >>>>>> void >>>>>> *buf, size_t size, bool wait) >>>>>> if (vi->hwrng_removed) >>>>>> return -ENODEV; >>>>>> >>>>>> + /* >>>>>> + * If the prev...

...gt;> b/drivers/char/hw_random/virtio-rng.c >>>>>> index 79a6e47b5fbc..984713b35892 100644 >>>>>> --- a/drivers/char/hw_random/virtio-rng.c >>>>>> +++ b/drivers/char/hw_random/virtio-rng.c >>>>>> @@ -59,6 +59,20 @@ static int virtio_read(struct hwrng *rng, >>>>>> void >>>>>> *buf, size_t size, bool wait) >>>>>> if (vi->hwrng_removed) >>>>>> return -ENODEV; >>>>>> >>>>>> + /* >>>>>> + * If the prev...

On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote: > On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote: > > When we try to hot-remove a busy virtio-rng device from QEMU monitor, > > the device can't be hot-removed. Because virtio-rng driver hangs at > > wait_for_completion_killable(). > > > > This patch fixed the hang by completing have_data completion

On (Wed) 06 Aug 2014 [16:05:41], Amos Kong wrote: > On Wed, Aug 06, 2014 at 01:35:15AM +0800, Amos Kong wrote: > > When we try to hot-remove a busy virtio-rng device from QEMU monitor, > > the device can't be hot-removed. Because virtio-rng driver hangs at > > wait_for_completion_killable(). > > > > This patch fixed the hang by completing have_data completion

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

...eve random data, it ends up in a >>>> tight >>>> loop with poll() always returning POLLIN and read() returning >>>> EAGAIN. >>>> This repeats forever until some process makes a blocking read() >>>> call. >>>> The reason is that virtio_read() always returns 0 in non-blocking >>>> mode, >>>> even if data is available. Worse, it fetches random data from the >>>> hypervisor after every non-blocking call, without ever using this >>>> data. >>>> >>>> The following tes...

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

...be waiting until > [hwrng] thread releases reading_mutex before we can continue. I think for 'virtio_rng' for 'O_NON_BLOCK' 'rng_get_data' returns without waiting for data which can let mutex to be used by other threads waiting if any? rng_dev_read rng_get_data virtio_read static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) { int ret; struct virtrng_info *vi = (struct virtrng_info *)rng->priv; if (vi->hwrng_removed) return -ENODEV; if (!vi->busy) { vi->busy = tru...

...hw_random/virtio-rng.c >>>> b/drivers/char/hw_random/virtio-rng.c >>>> index 79a6e47b5fbc..984713b35892 100644 >>>> --- a/drivers/char/hw_random/virtio-rng.c >>>> +++ b/drivers/char/hw_random/virtio-rng.c >>>> @@ -59,6 +59,20 @@ static int virtio_read(struct hwrng *rng, void >>>> *buf, size_t size, bool wait) >>>> if (vi->hwrng_removed) >>>> return -ENODEV; >>>> >>>> + /* >>>> + * If the previous call was non-blocking, we may have got some >>>> + * ra...

...e: > On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote: >> No problem. This code is tricky and it took me several months to really >> start to understand it ... > > Oh great, we actually have someone who understands the code! > Maybe you can help me understand: virtio_read > takes the buf pointer and puts it in the vq. > It can then return to caller (e.g. on a signal). > Device can meanwhile write into the buffer. > > It looks like if another call then happens, and that > other call uses a different buffer, virtio rng > will happily return the d...

...e: > On Tue, Aug 11, 2020 at 03:00:14PM +0200, Laurent Vivier wrote: >> No problem. This code is tricky and it took me several months to really >> start to understand it ... > > Oh great, we actually have someone who understands the code! > Maybe you can help me understand: virtio_read > takes the buf pointer and puts it in the vq. > It can then return to caller (e.g. on a signal). > Device can meanwhile write into the buffer. > > It looks like if another call then happens, and that > other call uses a different buffer, virtio rng > will happily return the d...

...leases reading_mutex before we can continue. > > I think for 'virtio_rng' for 'O_NON_BLOCK' 'rng_get_data' returns > without waiting for data which can let mutex to be used by other > threads waiting if any? > > rng_dev_read > rng_get_data > virtio_read As I said in the paragraph above the code that potentially holds the mutex for long time is the thread in hwrng core: hwrng_fillfn(). As it calls rng_get_data() with "wait" argument == 1 it may block while holding reading_mutex, which, in turn, will block rng_dev_read(), even if it was c...

...leases reading_mutex before we can continue. > > I think for 'virtio_rng' for 'O_NON_BLOCK' 'rng_get_data' returns > without waiting for data which can let mutex to be used by other > threads waiting if any? > > rng_dev_read > rng_get_data > virtio_read As I said in the paragraph above the code that potentially holds the mutex for long time is the thread in hwrng core: hwrng_fillfn(). As it calls rng_get_data() with "wait" argument == 1 it may block while holding reading_mutex, which, in turn, will block rng_dev_read(), even if it was c...

...opens /dev/hwrng with O_NONBLOCK and uses poll() and > non-blocking read() to retrieve random data, it ends up in a tight > loop with poll() always returning POLLIN and read() returning EAGAIN. > This repeats forever until some process makes a blocking read() call. > The reason is that virtio_read() always returns 0 in non-blocking mode, > even if data is available. Worse, it fetches random data from the > hypervisor after every non-blocking call, without ever using this data. > > The following test program illustrates the behavior and can be used > for testing and experiment...