search for: rng_dev_read

Amos Kong <akong at redhat.com> writes: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. I don't understand this explanation? I'd expect the sysfs process to be woken by the mutex_unlock(). If we're really high priority (vs. the sysfs process) then I can see...

Amos Kong <akong at redhat.com> writes: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. I don't understand this explanation? I'd expect the sysfs process to be woken by the mutex_unlock(). If we're really high priority (vs. the sysfs process) then I can see...

...redhat.com> writes: > > > When I check hwrng attributes in sysfs, cat process always gets > > > stuck if guest has only 1 vcpu and uses a slow rng backend. > > > > > > Currently we check if there is any tasks waiting to be run on > > > current cpu in rng_dev_read() by need_resched(). But need_resched() > > > doesn't work because rng_dev_read() is executing in user context. > > > > I don't understand this explanation? I'd expect the sysfs process to be > > woken by the mutex_unlock(). > > But actually sysfs pro...

...redhat.com> writes: > > > When I check hwrng attributes in sysfs, cat process always gets > > > stuck if guest has only 1 vcpu and uses a slow rng backend. > > > > > > Currently we check if there is any tasks waiting to be run on > > > current cpu in rng_dev_read() by need_resched(). But need_resched() > > > doesn't work because rng_dev_read() is executing in user context. > > > > I don't understand this explanation? I'd expect the sysfs process to be > > woken by the mutex_unlock(). > > But actually sysfs pro...

...caller. > > Is that right? > Yes. hw_random core uses two bufers: - rng_fillbuf that is used with a blocking access and protected by the reading_mutex. I think this cannot be interrupted by a kill because it's in hwrng_fillfn() and it's kthread. - rng_buffer that is used in rng_dev_read() and can be interrupted (it is also protected by reading_mutex) But if rng_dev_read() is called with O_NONBLOCK or interrupted and then rng_fillbuf starts they can be mixed. We have also the first use of rng_buffer in add_early_randomness() that use a different size than in rng_dev_read() with t...

...caller. > > Is that right? > Yes. hw_random core uses two bufers: - rng_fillbuf that is used with a blocking access and protected by the reading_mutex. I think this cannot be interrupted by a kill because it's in hwrng_fillfn() and it's kthread. - rng_buffer that is used in rng_dev_read() and can be interrupted (it is also protected by reading_mutex) But if rng_dev_read() is called with O_NONBLOCK or interrupted and then rng_fillbuf starts they can be mixed. We have also the first use of rng_buffer in add_early_randomness() that use a different size than in rng_dev_read() with t...

...2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index 263a370..b5d1b6f 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > mutex_unlock(&rng_mutex); > > - schedule_timeout_interruptible(1); > + schedule_timeout_interruptible(10); > > if (signal_pending(current)) { > err = -ERESTARTSYS; Does a schedule of 1 ms or 10 ms decrease the t...

...2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index 263a370..b5d1b6f 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > mutex_unlock(&rng_mutex); > > - schedule_timeout_interruptible(1); > + schedule_timeout_interruptible(10); > > if (signal_pending(current)) { > err = -ERESTARTSYS; Does a schedule of 1 ms or 10 ms decrease the t...

...- drivers/char/hw_random/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index 263a370..b5d1b6f 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, mutex_unlock(&rng_mutex); - schedule_timeout_interruptible(1); + schedule_timeout_interruptible(10); if (signal_pending(current)) { err = -ERESTARTSYS; -- 1.9.3

...nsertion(+), 1 deletion(-) > > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > > index 263a370..b5d1b6f 100644 > > --- a/drivers/char/hw_random/core.c > > +++ b/drivers/char/hw_random/core.c > > @@ -195,7 +195,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > > > > mutex_unlock(&rng_mutex); > > > > - schedule_timeout_interruptible(1); > > + schedule_timeout_interruptible(10); > > > > if (signal_pending(current)) { > > err = -ERESTARTSYS; > &g...

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

If we read hwrng by long-running dd process, it takes too much cpu time. When we check hwrng attributes from sysfs by cat, it gets stuck. The problem can only be reproduced with non-smp guest with slow backend. This patchset changed hwrng core to always delay 10 jiffies, cat process have chance to execute protected code, the problem is resolved. Thanks. Amos Kong (2): virtio-rng cleanup: move

...gt; lock to protect the read function and the static buffers, in preparation > > > for transition. > > > > > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > > > --- > > ... > > > > > > @@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char > > > __user *buf, > > > goto out_unlock; > > > } > > > > > > + mutex_lock(&reading_mutex); > > > > I think this breaks O_NONBLOCK: we have hwrng core thread t...

...gt; lock to protect the read function and the static buffers, in preparation > > > for transition. > > > > > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > > > --- > > ... > > > > > > @@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char > > > __user *buf, > > > goto out_unlock; > > > } > > > > > > + mutex_lock(&reading_mutex); > > > > I think this breaks O_NONBLOCK: we have hwrng core thread t...

On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. > > This patch removed need_resched() and increase delay to 10 jiffies, > then other tasks can have chance to execute protected code. > Delaying 1 jiffy also works, but 10...

On (Wed) 10 Sep 2014 [17:07:07], Amos Kong wrote: > When I check hwrng attributes in sysfs, cat process always gets > stuck if guest has only 1 vcpu and uses a slow rng backend. > > Currently we check if there is any tasks waiting to be run on > current cpu in rng_dev_read() by need_resched(). But need_resched() > doesn't work because rng_dev_read() is executing in user context. > > This patch removed need_resched() and increase delay to 10 jiffies, > then other tasks can have chance to execute protected code. > Delaying 1 jiffy also works, but 10...

...doesn't help (it leaves the current lock untouched), just adds a > lock to protect the read function and the static buffers, in preparation > for transition. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > --- ... > > @@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > goto out_unlock; > } > > + mutex_lock(&reading_mutex); I think this breaks O_NONBLOCK: we have hwrng core thread that is constantly pumps underlying rng for data; the thread takes the mutex...

...doesn't help (it leaves the current lock untouched), just adds a > lock to protect the read function and the static buffers, in preparation > for transition. > > Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> > --- ... > > @@ -160,13 +166,14 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf, > goto out_unlock; > } > > + mutex_lock(&reading_mutex); I think this breaks O_NONBLOCK: we have hwrng core thread that is constantly pumps underlying rng for data; the thread takes the mutex...

...long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat process can have chance to get the lock and execute protected code without stuck. Thanks. V2: update commitlog to describe PATCH 2, split second patch. Amos Kong (3): virtio-rng cleanup: move some code out of mutex protection...

...long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat process can have chance to get the lock and execute protected code without stuck. Thanks. V2: update commitlog to describe PATCH 2, split second patch. Amos Kong (3): virtio-rng cleanup: move some code out of mutex protection...