Interesting anti-pattern.
Signed-off-by: Rusty Russell
---
drivers/char/hw_random/core.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index b4a21e9521cf..6a34feca6b43 100644
--- a/drivers/char/hw_random/cor
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
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
---
drivers/char/hw_random/core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/char/hw_
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 unde
Another interesting anti-pattern.
Signed-off-by: Rusty Russell
---
drivers/char/hw_random/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 6a34feca6b43..96fa06716e95 100644
--- a/drivers/char/hw_random/core.c
+++ b/driv
Hi all-
I would like to standardize on a very simple protocol by which a guest
OS can obtain an RNG seed early in boot.
The main design requirements are:
- The interface should be very easy to use. Linux, at least, will
want to use it extremely early in boot as part of kernel ASLR. This
means
Amos Kong 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
On Thu, Sep 18, 2014 at 3:09 AM, David Hildenbrand
wrote:
>> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe wrote:
>> >
>> > Another way would be to ensure that the timeout handler doesn't touch
>> > hw_ctx
>> > or tag_sets that aren't fully initialized yet. But I think this is
>> > safer/cleaner.
On 09/17/2014 01:09 PM, David Hildenbrand wrote:
>>> 0. That should already be sufficient to hinder blk_mq_tag_to_rq and the
>>> calling
>>> method to do the wrong thing.
>>
>> Yes, clearing rq->cmd_flags should be enough.
>>
>> And looks better to move rq initialization to __blk_mq_free_request()
> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe wrote:
> >
> > Another way would be to ensure that the timeout handler doesn't touch hw_ctx
> > or tag_sets that aren't fully initialized yet. But I think this is
> > safer/cleaner.
>
> That may not be easy or enough to check if hw_ctx/tag_sets are
>
On Wed, 2014-09-17 at 09:07 -0700, Andy Lutomirski wrote:
>
> I still think that this is a property of the bus, not the device. x86
> has such a mechanism, and this patch uses it transparently.
Right. A device driver should use the DMA API. Always.
The platform's implementation of the DMA API i
On Wed, Sep 17, 2014 at 9:09 AM, Ira W. Snyder wrote:
> On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote:
>> On non-PPC systems, virtio_pci should use the DMA API. This fixes
>> virtio_pci on Xen. On PPC, using the DMA API would break things, so
>> we need to preserve the old beha
On Tue, Sep 16, 2014 at 10:22:27PM -0700, Andy Lutomirski wrote:
> On non-PPC systems, virtio_pci should use the DMA API. This fixes
> virtio_pci on Xen. On PPC, using the DMA API would break things, so
> we need to preserve the old behavior.
>
> The big comment in this patch explains the consid
On Sep 17, 2014 7:13 AM, "Michael S. Tsirkin" wrote:
>
> On Wed, Sep 17, 2014 at 08:02:31AM -0400, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote:
> > > On non-PPC systems, virtio_pci should use the DMA API. This fixes
> > > virtio_pci on Xen. On PPC,
On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe wrote:
>
> Another way would be to ensure that the timeout handler doesn't touch hw_ctx
> or tag_sets that aren't fully initialized yet. But I think this is
> safer/cleaner.
That may not be easy or enough to check if hw_ctx/tag_sets are
fully initializ
On 2014-09-17 07:52, Ming Lei wrote:
On Wed, 17 Sep 2014 14:00:34 +0200
David Hildenbrand wrote:
Does anyone have an idea?
The request itself is completely filled with cc
That is very weird, the 'rq' is got from hctx->tags, and rq should be
valid, and rq->q shouldn't have been changed even
On Wed, Sep 17, 2014 at 08:02:31AM -0400, Benjamin Herrenschmidt wrote:
> On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote:
> > On non-PPC systems, virtio_pci should use the DMA API. This fixes
> > virtio_pci on Xen. On PPC, using the DMA API would break things, so
> > we need to preserve
> >>> Does anyone have an idea?
> >>> The request itself is completely filled with cc
> >>
> >> That is very weird, the 'rq' is got from hctx->tags, and rq should be
> >> valid, and rq->q shouldn't have been changed even though it was
> >> double free or double allocation.
> >>
> >>> I am currentl
> On Wed, 17 Sep 2014 14:00:34 +0200
> David Hildenbrand wrote:
>
> > > >>> Does anyone have an idea?
> > > >>> The request itself is completely filled with cc
> > > >>
> > > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be
> > > >> valid, and rq->q shouldn't have been ch
On Wed, 17 Sep 2014 14:00:34 +0200
David Hildenbrand wrote:
> > >>> Does anyone have an idea?
> > >>> The request itself is completely filled with cc
> > >>
> > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be
> > >> valid, and rq->q shouldn't have been changed even thoug
On Tue, 2014-09-16 at 22:22 -0700, Andy Lutomirski wrote:
> On non-PPC systems, virtio_pci should use the DMA API. This fixes
> virtio_pci on Xen. On PPC, using the DMA API would break things, so
> we need to preserve the old behavior.
>
> The big comment in this patch explains the consideration
On Wed, Sep 17, 2014 at 3:59 PM, Christian Borntraeger
wrote:
> On 09/12/2014 10:09 PM, Christian Borntraeger wrote:
>> On 09/12/2014 01:54 PM, Ming Lei wrote:
>>> On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger
>>> wrote:
Folks,
we have seen the following bug with 3.16 as a
On Tuesday, September 09, 2014 9:14 AM, Rusty Russell wrote:
> Jingoo Han writes:
> > Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler.
> >
> > Signed-off-by: Jingoo Han
>
> This patch is obviously wrong. It won't compile without
> CONFIG_PM_SLEEP.
No, there is no compile issue.
W
On Tue, Sep 16, 2014 at 12:02:26AM +0800, Amos Kong wrote:
> If we read hwrng by 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 reproduc
On 09/12/2014 10:09 PM, Christian Borntraeger wrote:
> On 09/12/2014 01:54 PM, Ming Lei wrote:
>> On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger
>> wrote:
>>> Folks,
>>>
>>> we have seen the following bug with 3.16 as a KVM guest. It suspect the
>>> blk-mq rework that happened between 3.1
25 matches
Mail list logo
