Displaying 20 results from an estimated 34 matches for "rng_fillbuf".
2020 Aug 11
2
[PATCH v2] virtio-rng: return available data with O_NONBLOCK
...e buffer.
>
> It looks like if another call then happens, and that
> other call uses a different buffer, virtio rng
> will happily return the data written into the
> original buf pointer, confusing the 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_...
2020 Aug 11
2
[PATCH v2] virtio-rng: return available data with O_NONBLOCK
...e buffer.
>
> It looks like if another call then happens, and that
> other call uses a different buffer, virtio rng
> will happily return the data written into the
> original buf pointer, confusing the 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_...
2014 Dec 08
0
[PATCH v5 REPOST 1/6] hw_random: place mutex around read functions and buffers.
...core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
static struct hwrng *current_rng;
static struct task_struct *hwrng_fill;
static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
+ mutex_lock(&reading_mutex);
byte...
2014 Sep 18
2
[PATCH 1/5] hw_random: place mutex around read functions and buffers.
...core.c
+++ b/drivers/char/hw_random/core.c
@@ -53,7 +53,10 @@
static struct hwrng *current_rng;
static struct task_struct *hwrng_fill;
static LIST_HEAD(rng_list);
+/* Protects rng_list and current_rng */
static DEFINE_MUTEX(rng_mutex);
+/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
+static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
static unsigned short current_quality;
@@ -81,7 +84,9 @@ static void add_early_randomness(struct hwrng *rng)
unsigned char bytes[16];
int bytes_read;
+ mutex_lock(&reading_mutex);
byte...
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 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 18
6
[PATCH v2 2/3] hw_random: fix stuck in catting hwrng attributes
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
2014 Sep 18
6
[PATCH v2 2/3] hw_random: fix stuck in catting hwrng attributes
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
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
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
2020 Aug 11
0
[PATCH v2] virtio-rng: return available data with O_NONBLOCK
...ens, and that
> > other call uses a different buffer, virtio rng
> > will happily return the data written into the
> > original buf pointer, confusing the 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 readin...
2014 Oct 21
1
[PATCH 3/5] hw_random: fix unregister race.
...hw_random/core.c
> index dc9092a1075d..b4a21e9521cf 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
> static DEFINE_MUTEX(reading_mutex);
> static int data_avail;
> static u8 *rng_buffer, *rng_fillbuf;
> +static DECLARE_WAIT_QUEUE_HEAD(rng_done);
> static unsigned short current_quality;
> static unsigned short default_quality; /* = 0; default to "off" */
>
> @@ -98,6 +99,7 @@ static inline void cleanup_rng(struct kref *kref)
>
> if (rng->cleanup)
>...
2014 Oct 21
1
[PATCH 3/5] hw_random: fix unregister race.
...hw_random/core.c
> index dc9092a1075d..b4a21e9521cf 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -60,6 +60,7 @@ static DEFINE_MUTEX(rng_mutex);
> static DEFINE_MUTEX(reading_mutex);
> static int data_avail;
> static u8 *rng_buffer, *rng_fillbuf;
> +static DECLARE_WAIT_QUEUE_HEAD(rng_done);
> static unsigned short current_quality;
> static unsigned short default_quality; /* = 0; default to "off" */
>
> @@ -98,6 +99,7 @@ static inline void cleanup_rng(struct kref *kref)
>
> if (rng->cleanup)
>...
2020 Aug 11
2
[PATCH v2] virtio-rng: return available data with O_NONBLOCK
On 11/08/2020 14:53, Martin Wilck wrote:
> On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote:
>> On 11/08/2020 14:22, Martin Wilck wrote:
>>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote:
>>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++
>>>>>> 1 file changed, 14 insertions(+)
>>>>>>
2020 Aug 11
2
[PATCH v2] virtio-rng: return available data with O_NONBLOCK
On 11/08/2020 14:53, Martin Wilck wrote:
> On Tue, 2020-08-11 at 14:39 +0200, Laurent Vivier wrote:
>> On 11/08/2020 14:22, Martin Wilck wrote:
>>> On Tue, 2020-08-11 at 14:02 +0200, Laurent Vivier wrote:
>>>>>> drivers/char/hw_random/virtio-rng.c | 14 ++++++++++++++
>>>>>> 1 file changed, 14 insertions(+)
>>>>>>
2014 Sep 18
2
[PATCH v2 3/6] hw_random: use reference counts on each struct hwrng.
...n(void *unused)
> long rc;
>
> while (!kthread_should_stop()) {
> - if (!current_rng)
> + struct hwrng *rng;
> +
> + rng = get_current_rng();
> + if (IS_ERR(rng) || !rng)
> break;
> mutex_lock(&reading_mutex);
> - rc = rng_get_data(current_rng, rng_fillbuf,
> + rc = rng_get_data(rng, rng_fillbuf,
> rng_buffer_size(), 1);
> mutex_unlock(&reading_mutex);
> + put_rng(rng);
> if (rc <= 0) {
> pr_warn("hwrng: no data available\n");
> msleep_interruptible(10000);
> @@ -423,14 +475,13 @@ int hw...