Displaying 20 results from an estimated 80 matches for "rng_mutex".
2014 Sep 09
2
mutex
...wrng of=/dev/null' in guest
- check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*'
Result: cat process will get stuck, it will return if we kill dd process.
We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
they are protected by rng_mutex. I try to workaround this issue by undelay(100)
after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show()
to get mutex.
This patch also contains some cleanup, moving some code out of mutex
protection.
Do you have some suggestion? Thanks.
diff --git a/drivers/char/hw_rand...
2014 Sep 09
2
mutex
...wrng of=/dev/null' in guest
- check sysfs files in the same time, 'cat /sys/class/misc/hw_random/rng_*'
Result: cat process will get stuck, it will return if we kill dd process.
We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
they are protected by rng_mutex. I try to workaround this issue by undelay(100)
after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show()
to get mutex.
This patch also contains some cleanup, moving some code out of mutex
protection.
Do you have some suggestion? Thanks.
diff --git a/drivers/char/hw_rand...
2014 Sep 18
2
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
>
> Using a kref is overkill (we're always under the rng_mutex), but
> a standard pattern.
>
> This also solves the problem that the hwrn...
2014 Sep 18
2
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
>
> Using a kref is overkill (we're always under the rng_mutex), but
> a standard pattern.
>
> This also solves the problem that the hwrn...
2014 Sep 18
9
[PATCH v2 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 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:
|
2014 Sep 18
9
[PATCH v2 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 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:
|
2014 Sep 10
2
RFC virtio-rng: fail to read sysfs of a busy device
...n
/dev/hwrng?
Also, with the new khwrng thread, reading from /dev/hwrng isn't
required -- just use /dev/random?
(This doesn't mean we shouldn't fix the issue here...)
> We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
> they are protected by rng_mutex. I try to workaround this issue by undelay(100)
> after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show()
> to get mutex.
>
> This patch also contains some cleanup, moving some code out of mutex
> protection.
>
> Do you have some suggestion? Thanks....
2014 Sep 10
2
RFC virtio-rng: fail to read sysfs of a busy device
...n
/dev/hwrng?
Also, with the new khwrng thread, reading from /dev/hwrng isn't
required -- just use /dev/random?
(This doesn't mean we shouldn't fix the issue here...)
> We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c,
> they are protected by rng_mutex. I try to workaround this issue by undelay(100)
> after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show()
> to get mutex.
>
> This patch also contains some cleanup, moving some code out of mutex
> protection.
>
> Do you have some suggestion? Thanks....
2014 Sep 18
0
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Nov 03
1
[PATCH v4 3/6] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Nov 03
1
[PATCH v4 3/6] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Oct 20
0
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
...> + kref_init(&rng->ref);
> +
> return 0;
> }
OK, I folded this fix on.
Thanks,
Rusty.
hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Oct 20
0
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
...> + kref_init(&rng->ref);
> +
> return 0;
> }
OK, I folded this fix on.
Thanks,
Rusty.
hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Sep 18
0
[PATCH 2/5] hw_random: use reference counts on each struct hwrng.
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 /dev/hwrng.
Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.
This also solves the problem that the hwrng_fillfn thread was
accessing curre...
2014 Dec 06
7
[PATCH v5 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
2014 Dec 06
7
[PATCH v5 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
2014 Nov 03
9
[PATCH v4 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
2014 Nov 03
9
[PATCH v4 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
2014 Dec 08
8
[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
2014 Dec 08
8
[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