From: Eric Biggers
Date: Thu, 9 Feb 2017 10:29:14 -0800
> On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote:
>> >
>> > [Also, for some reason linux-crypto is apparently still not receiving
>> > patch 1/5
>> > in the series. It's missing from the linux-crypto archive at
>> > http://w
On Thu, Feb 9, 2017 at 10:14 PM, Dan Williams wrote:
> On Thu, Feb 9, 2017 at 1:29 AM, Anup Patel wrote:
>> On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams
>> wrote:
>>> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote:
On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams
wrote:
> On Tu
Hi Herbert,
On Mon, 6 Feb 2017 17:03:40 +0800 Herbert Xu
wrote:
>
> On Mon, Feb 06, 2017 at 12:28:37PM +1100, Stephen Rothwell wrote:
> >
> > After merging the crypto tree, today's linux-next build (x86_64
> > allmodconfig) produced these warnings:
> >
> > warning: (CRYPTO_DEV_ATMEL_AUTHENC) s
Hi David,
> > --- a/crypto/asymmetric_keys/public_key.c
> > +++ b/crypto/asymmetric_keys/public_key.c
> > @@ -184,8 +184,10 @@ static int software_key_eds_op(struct
> kernel_pkey_params *params,
> > return PTR_ERR(tfm);
> >
> > req = akcipher_request_alloc(tfm, GFP_KERNEL);
> > -
Hello Sven,
On Thu, Feb 09, 2017 at 11:56:17AM +0100, Sven Schmidt wrote:
> Hey Minchan,
>
> On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
> > Hello Sven,
> >
> > On Sun, Feb 05, 2017 at 08:09:03PM +0100, Sven Schmidt wrote:
> > >
> > > This patchset is for updating the LZ4 compr
Hello Eric,
On Wed, Feb 08, 2017 at 09:24:25PM -0800, Eric Biggers wrote:
> Also I noticed another bug, this time in LZ4_count():
>
> > #if defined(CONFIG_64BIT)
> > #define LZ4_ARCH64 1
> > #else
> > #define LZ4_ARCH64 0
> > #endif
> ...
> > #ifdef LZ4_ARCH64
> >if ((pIn < (pInLimit-3))
The following series implements...
- Move verbose init messages to debug mode
- Update the queue pointers in the event of an error
- Simply buffer management and eliminate an unused option
---
Gary R Hook (3):
crypto: ccp - Change mode for detailed CCP init messages
crypto: ccp -
Move the command queue tail pointer when an error is
detected. Always return the error.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
i
The CCP initialization messages only need to be sent to
syslog in debug mode.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index e2ce81
The reverse-get/set functions can be simplified by
eliminating unused code.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-ops.c | 142 +-
1 file changed, 56 insertions(+), 86 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypt
On Thu, Feb 09, 2017 at 01:13:22AM -0700, Alden Tondettar wrote:
> And using:
>
> $ qemu-system-x86_64 --version
> QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c)
> 2003-2008 Fabrice Bellard
> $ qemu-system-x86_64 -nographic -enable-kvm -m 1024M -kernel bzImage -append
>
OK, I figured out what is going on with your test results.
If you use qemu-system-x86_64 **without** --enable-kvm, then on both
the Debian Jessie version of qemu as well as the Debian Stretch
version of qemu, crng_fast_load() will be called _twice_ before
crng_initialize has a chance to be called.
On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote:
> >
> > [Also, for some reason linux-crypto is apparently still not receiving patch
> > 1/5
> > in the series. It's missing from the linux-crypto archive at
> > http://www.spinics.net/lists/linux-crypto/, so it's not just me.]
> >
>
On Thu, Feb 09, 2017 at 12:05:40PM +0100, Sven Schmidt wrote:
> > Because of how LZ4_ARCH64 is defined, it needs to be '#if LZ4_ARCH64'.
> >
> > But I also think the way upstream LZ4 does 64-bit detection could have just
> > been
> > left as-is; it has a function which gets inlined:
> >
> >
Wei Yongjun wrote:
> --- a/crypto/asymmetric_keys/public_key.c
> +++ b/crypto/asymmetric_keys/public_key.c
> @@ -184,8 +184,10 @@ static int software_key_eds_op(struct kernel_pkey_params
> *params,
> return PTR_ERR(tfm);
>
> req = akcipher_request_alloc(tfm, GFP_KERNEL);
>
This patch fixes a previous patch: "crypto: atmel-sha - update request
queue management to make it more generic".
Indeed the patch above should have replaced the "return -EINVAL;" lines by
"return atmel_sha_complete(dd, -EINVAL);" but instead replaced them by a
simple call of "atmel_sha_complete(d
Hi all,
this series is based on next-20170209.
The first patch fixes a bug reported by Dan Carpenter. I didn't put a
Fixes tag since the buggy patch is only in linux-next for now so its
commit ID is likely to change when entering Linus' tree.
It fixes a wrong 'sed' command:
This patch clarifies and fixes how errors should be handled by
atmel_sha_start().
For update operations, the previous code wrongly assumed that
(err != -EINPROGRESS) implies (err == 0). It's wrong because that doesn't
take the error cases (err < 0) into account.
This patch also adds many comments
On Thu, Feb 9, 2017 at 1:29 AM, Anup Patel wrote:
> On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams wrote:
>> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote:
>>> On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams
>>> wrote:
On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel wrote:
> On Tue, Feb 7
From: Wei Yongjun
Fix to return error code -ENOMEM from the akcipher_request_alloc()
error handling case instead of 0.
Signed-off-by: Wei Yongjun
---
crypto/asymmetric_keys/public_key.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/public_ke
Hey Eric,
On Wed, Feb 08, 2017 at 09:24:25PM -0800, Eric Biggers wrote:
> Also I noticed another bug, this time in LZ4_count():
>
> > #if defined(CONFIG_64BIT)
> > #define LZ4_ARCH64 1
> > #else
> > #define LZ4_ARCH64 0
> > #endif
> ...
> > #ifdef LZ4_ARCH64
> >if ((pIn < (pInLimit-3))
>
Hey Eric,
On Wed, Feb 08, 2017 at 04:24:36PM -0800, Eric Biggers wrote:
> On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
> >
> > Today, I did zram-lz4 performance test with fio in current mmotm and
> > found it makes regression about 20%.
> >
>
> This may or may not be the cause o
Hey Minchan,
On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
> Hello Sven,
>
> On Sun, Feb 05, 2017 at 08:09:03PM +0100, Sven Schmidt wrote:
> >
> > This patchset is for updating the LZ4 compression module to a version based
> > on LZ4 v1.7.3 allowing to use the fast compression alg
Am Mittwoch, 8. Februar 2017, 17:57:23 CET schrieb Linus Torvalds:
Hi Linus,
> Stephan, Herbert? The zeroes in /dev/hwrng output are obviously
> complete crap, so there's something badly wrong somewhere.
>
> The locking, for example, is completely buggered. There's even a
> comment about it, but
On Wed, Feb 8, 2017 at 9:54 PM, Dan Williams wrote:
> On Wed, Feb 8, 2017 at 12:57 AM, Anup Patel wrote:
>> On Tue, Feb 7, 2017 at 11:46 PM, Dan Williams
>> wrote:
>>> On Tue, Feb 7, 2017 at 1:02 AM, Anup Patel wrote:
On Tue, Feb 7, 2017 at 1:57 PM, Dan Williams
wrote:
> On Tue
Am Donnerstag, 9. Februar 2017, 02:04:32 CET schrieb Alden Tondettar:
Hi Alden,
> On Thu, Feb 09, 2017 at 07:47:25AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote:
> > > In short, the situation is:
> > >
> > > A) No usable hardware RNG or ar
On Thu, Feb 09, 2017 at 02:04:32AM -0700, Alden Tondettar wrote:
> On Thu, Feb 09, 2017 at 07:47:25AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote:
> > > In short, the situation is:
> > >
> > > A) No usable hardware RNG or arch_get_random() (
On Thu, Feb 09, 2017 at 07:47:25AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote:
> > In short, the situation is:
> >
> > A) No usable hardware RNG or arch_get_random() (or we don't trust it...)
>
> Wait, why would you not trust arch_get_random
On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote:
>
> Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform
> Arm64) and it works just fine.
>
> Tested-by: Gilad Ben-Yossef
>
Hi Gilad,
Thank you for testing it. Do you have access to a device having crypto
hardware with IV ge
On Wed, Feb 08, 2017 at 11:19:31PM -0500, Theodore Ts'o wrote:
> How did you determine when crng_initialize() was being called? On a
> VM generally there are fewer interrupts than on real hardware. On
> KVM, for I see the random: fast_init message being printed 3.6 seconds
> into the boot.
>
> O
30 matches
Mail list logo
