Re: [PATCH v2 25/25] crypto: ansi_cprng - If non-deterministic, don't buffer old output

> Not your motivations, just the posting mechanics. If you just want to > discuss a patch, and aren't yet proposing it for inclusion, you should > put RFC in the prefix of every patch header. I understand the principle, and I should have on those patches (mea culpa), but really *all* patch postin

Re: [PATCH] crypto: qat - add support for cbc(aes) ablkcipher

On 12/08/2014 12:08 PM, Tadeusz Struk wrote: > Add support for cbc(aes) ablkcipher. > Hi Herbert, These two: [PATCH] crypto: qat - add support for cbc(aes) ablkcipher [PATCH] crypto: qat - Fix assumption that sg in and out will have the... are generated against cryptodev with these two on top:

[PATCH] crypto: qat - add support for cbc(aes) ablkcipher

Add support for cbc(aes) ablkcipher. Signed-off-by: Tadeusz Struk Acked-by: Bruce W. Allan --- drivers/crypto/qat/qat_common/icp_qat_hw.h |2 drivers/crypto/qat/qat_common/qat_algs.c | 528 ++-- drivers/crypto/qat/qat_common/qat_crypto.h | 15 + 3 files changed

[PATCH] crypto: qat - Fix assumption that sg in and out will have the same nents

Fixed invalid assumpion that the sgl in and sgl out will always have the same number of entries. Signed-off-by: Tadeusz Struk --- drivers/crypto/qat/qat_common/qat_algs.c | 82 +--- drivers/crypto/qat/qat_common/qat_crypto.h |1 2 files changed, 50 insertions(+),

[PATCH v3] crypto: algif - Mark sgl end at the end of data

Hi, algif_skcipher sends 127 sgl buffers for encryption regardless of how many buffers acctually have data to process, where the few first with valid len and the rest with zero len. This is not very eficient. This patch marks the last one with data as the last one to process. Changes: v2 - use dat

Re: [PATCH v2 25/25] crypto: ansi_cprng - If non-deterministic, don't buffer old output

On Mon, Dec 08, 2014 at 11:43:13AM -0500, George Spelvin wrote: > > Wait, I'm confused. You mention in this note that this is an RFC patch, but > > not > > anywhere else in the series. Are you proposing this for inclusion or not? > > Er, in the 0/25, I mentioned that I put the least certain stuf

Re: [PATCH v2 25/25] crypto: ansi_cprng - If non-deterministic, don't buffer old output

> Wait, I'm confused. You mention in this note that this is an RFC patch, but > not > anywhere else in the series. Are you proposing this for inclusion or not? Er, in the 0/25, I mentioned that I put the least certain stuff last, and in particular I wasn't sure if the the last three patches were

Re: [PATCH v2 25/25] crypto: ansi_cprng - If non-deterministic, don't buffer old output

On Sun, Dec 07, 2014 at 05:49:59PM -0500, George Spelvin wrote: > By the way, this patch includes a bug due to a last minute "oh, I can > make that more efficient!" which I realized after a night's sleep. > (The v1 patch worked, FWIW.) > > Anyway, it's an RFC; I'm not even sure if I want this pers

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

From: Rusty Russell 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. v5: reset cleanup_done flag, use compiler barrier to prevent recording. v4: add cleanup_done flag to insure that cle

[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: | g

[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 --- drivers/ch

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

From: Rusty Russell 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 overk

[PATCH v5 REPOST 5/6] hw_random: don't double-check old_rng.

From: Rusty Russell 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 067270b..a9286bf 100644 --- a/drivers/char/h

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

From: Rusty Russell 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 backen

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

From: Rusty Russell 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 a9286bf..4d13ac5 100644 --- a/drivers/char/hw_random/core.