[PATCH v5 REPOST 6/6] hw_random: don't init list element we're about to add to list.

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

[PATCH v5 REPOST 1/6] hw_random: place mutex around read functions and buffers.

From: Rusty Russell ru...@rustcorp.com.au 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

[PATCH v5 REPOST 0/6] fix hw_random stuck

corrupt, decrease last reference for triggering the cleanup, fix unregister race pointed by Herbert V3: initialize kref to 1 V2: added patch 2 to fix a deadlock, update current patch 3 to fix reference counting issue Amos Kong (1): hw_random: move some code out mutex_lock for avoiding

[PATCH v5 REPOST 2/6] hw_random: move some code out mutex_lock for avoiding underlying deadlock

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 ak

[PATCH v5 REPOST 3/6] hw_random: use reference counts on each struct hwrng.

for triggering the cleanup v3: initialize kref (thanks Amos Kong) v2: fix missing put_rng() on exit path (thanks Amos Kong) Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Amos Kong ak...@redhat.com --- drivers/char/hw_random/core.c | 135

[PATCH v5 REPOST 4/6] hw_random: fix unregister race.

flag to insure that cleanup is done Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Amos Kong ak...@redhat.com --- drivers/char/hw_random/core.c | 12 include/linux/hw_random.h | 1 + 2 files changed, 13 insertions(+) diff --git a/drivers/char/hw_random/core.c b

Re: [PATCH] crypto/xor.c: use 2 pages for xor speed testing

On Thu, Jun 05, 2014 at 11:57:55PM +0200, Marek Vasut wrote: On Thursday, June 05, 2014 at 03:11:33 AM, Amos Kong wrote: In crypto/xor.c: calibrate_xor_blocks(), we allocated total 4 pages to do xor speed testing, the BENCH_SIZE is 1 page, and we skipped 2 pages when we set b2

Re: RFC: 2 pages are enough for xor speed testing

On Sun, Jun 01, 2014 at 06:53:31PM +0200, Marek Vasut wrote: On Wednesday, May 28, 2014 at 07:01:52 AM, Amos Kong wrote: @@ -154,7 +154,7 @@ calibrate_xor_blocks(void) #undef xor_speed out: - free_pages((unsigned long)b1, 2); + free_pages((unsigned long)b1, 1

[PATCH] crypto/xor.c: use 2 pages for xor speed testing

In crypto/xor.c: calibrate_xor_blocks(), we allocated total 4 pages to do xor speed testing, the BENCH_SIZE is 1 page, and we skipped 2 pages when we set b2. It seems that total 2 pages are enough without skipping 2 pages. Signed-off-by: Amos Kong ak...@redhat.com --- crypto/xor.c | 6 +++--- 1

RFC: 2 pages are enough for xor speed testing

In crypto/xor.c: calibrate_xor_blocks(), we allocated total 4 pages to do xor speed testing, the BENCH_SIZE is 1 page. Why do we skip 2 pages when we set *b2? It seems that total 2 pages are enough. diff --git a/crypto/xor.c b/crypto/xor.c index 35d6b3a..38421a1 100644 --- a/crypto/xor.c +++