On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
arch/x86/include/asm/pvqspinlock.h| 411
+
I do wonder why all this needs to live in x86..
+#ifdef CONFIG_QUEUE_SPINLOCK
+
+static __always_inline void pv_kick_cpu(int cpu)
+{
+
On Thu, 30 Oct 2014 23:29:50 +0100
Greg Kurz gk...@linux.vnet.ibm.com wrote:
On Thu, 30 Oct 2014 19:02:01 +0100
Cornelia Huck cornelia.h...@de.ibm.com wrote:
On Tue, 28 Oct 2014 16:40:18 +0100
Greg Kurz gk...@linux.vnet.ibm.com wrote:
On Tue, 7 Oct 2014 16:40:01 +0200
Cornelia
On Mon, Nov 03, 2014 at 12:10:49PM +, One Thousand Gnomes wrote:
On Sun, 2 Nov 2014 09:33:01 -0800
Josh Triplett j...@joshtriplett.org wrote:
On the vast majority of modern systems, no processes will use the
userspsace IO syscalls, iopl and ioperm. Add a new config option,
On Tue, Oct 21, 2014 at 10:15:23PM +0800, Herbert Xu wrote:
On Thu, Sep 18, 2014 at 12:18:24PM +0930, Rusty Russell wrote:
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.
In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: Amos Kong
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:
|
From: Rusty Russell ru...@rustcorp.com.au
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.
v4: add cleanup_done flag to insure that cleanup is done
Signed-off-by: Rusty Russell
From: Rusty Russell ru...@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.
From: Rusty Russell ru...@rustcorp.com.au
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
From: Rusty Russell ru...@rustcorp.com.au
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
On Mon, Nov 03, 2014 at 03:27:48PM +, One Thousand Gnomes wrote:
This isn't unreasonable but there are drivers with userspace helpers that
use iopl/ioperm type functionality where you should be doing a SELECT of
X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick
On 11/03/2014 07:27 AM, One Thousand Gnomes wrote:
This isn't unreasonable but there are drivers with userspace helpers that
use iopl/ioperm type functionality where you should be doing a SELECT of
X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick
scan it may these days
On 11/03/2014 05:35 AM, Peter Zijlstra wrote:
On Wed, Oct 29, 2014 at 04:19:09PM -0400, Waiman Long wrote:
arch/x86/include/asm/pvqspinlock.h| 411 +
I do wonder why all this needs to live in x86..
I haven't looked into the para-virtualization code in
On Sat, Oct 11, 2014 at 06:51:47AM +0800, Amos Kong wrote:
I received two mails about faile to apply patches to 3.16-stable tree:
FAILED: patch [PATCH] virtio-rng: skip reading when we start to remove the
device failed to apply to 3.16-stable tree
FAILED: patch [PATCH] virtio-rng: fix stuck
14 matches
Mail list logo
