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
borntrae...@de.ibm.com wrote:
Folks,
we have seen the following bug with 3.16 as a KVM guest. It suspect the
blk-mq rework that happened
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 reproduced
On Tuesday, September 09, 2014 9:14 AM, Rusty Russell wrote:
Jingoo Han jg1@samsung.com writes:
Use SIMPLE_DEV_PM_OPS macro in order to make the code simpler.
Signed-off-by: Jingoo Han jg1@samsung.com
This patch is obviously wrong. It won't compile without
CONFIG_PM_SLEEP.
No,
On Wed, Sep 17, 2014 at 3:59 PM, Christian Borntraeger
borntrae...@de.ibm.com 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
borntrae...@de.ibm.com wrote:
Folks,
we have seen the
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 considerations in
On Wed, 17 Sep 2014 14:00:34 +0200
David Hildenbrand d...@linux.vnet.ibm.com 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
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 currently asking myself if
On Wed, 17 Sep 2014 14:00:34 +0200
David Hildenbrand d...@linux.vnet.ibm.com 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
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 the
On 2014-09-17 07:52, Ming Lei wrote:
On Wed, 17 Sep 2014 14:00:34 +0200
David Hildenbrand d...@linux.vnet.ibm.com 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
On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe ax...@kernel.dk 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 Sep 17, 2014 7:13 AM, Michael S. Tsirkin m...@redhat.com 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
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
On Wed, Sep 17, 2014 at 9:09 AM, Ira W. Snyder i...@ovro.caltech.edu 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
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 is
On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe ax...@kernel.dk 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
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()
too, otherwise
On Thu, Sep 18, 2014 at 3:09 AM, David Hildenbrand
d...@linux.vnet.ibm.com wrote:
On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe ax...@kernel.dk 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
Amos Kong ak...@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
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
Another interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
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
---
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 ru...@rustcorp.com.au
---
drivers/char/hw_random/core.c | 5 +
1 file changed, 5 insertions(+)
diff
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
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
Interesting anti-pattern.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
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
---
25 matches
Mail list logo
