On Tue, Jun 28, 2016 at 10:32:12AM -0400, George Spelvin wrote:
>
> - struct crypto_instance
> - struct crypto_spawn
> - struct crypto_blkcipher
> - struct blkcipher_desc
> - More on the context structures returned by crypto_tfm_ctx
blkcipher is obsolete and will be removed soon. So if you are
g
Remove redundant sg_init_table call. scatterwalk_ffwd doing the same.
Signed-off-by: Harsh Jain
---
crypto/authenc.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index 55a354d..c7cc11d 100644
--- a/crypto/authenc.c
+++ b/crypt
Hi Dave & Folks,
Today I'm releasing WireGuard, an encrypted and authenticated
tunneling virtual interface for the kernel. It uses next-generation
cryptography and is designed to be both easy to use and simple to
implement (only ~4000 LoC, which compared to xfrm or openvpn is
spectacular), avoidin
> We have actually gained quite a bit of documentation recently.
> Have you looked at Documentation/DocBook/crypto-API.tmpl?
>
> More is always welcome of course.
It's improved since I last looked at it, but there are still many structures
that aren't described:
- struct crypto_instance
- struct
On Tue, Jun 28, 2016 at 09:23:01AM -0400, George Spelvin wrote:
>
> Wow, I should see how you do that. I couldn't get it below 3
> blocks of temporary, and the dst SG list only gives you
> one and a half.
I don't mean that I'm using no temporary buffers at all, just
that the actual crypto only o
Herbert Xu wrote:
> I'm currently working on cts and I'm removing the stack usage
> altogether by having it operate on the src/dst SG lists only.
Wow, I should see how you do that. I couldn't get it below 3
blocks of temporary, and the dst SG list only gives you
one and a half.
> BTW, the only c
On Tue, Jun 28, 2016 at 08:37:43AM -0400, George Spelvin wrote:
> Just a note, crypto/cts.c also does a lot of sg_set_buf() in stack buffers.
>
> I have a local patch (appended, if anyone wants) to reduce the wasteful
> amount of buffer space it uses (from 7 to 3 blocks on encrypt, from
> 6 to 3 b
Just a note, crypto/cts.c also does a lot of sg_set_buf() in stack buffers.
I have a local patch (appended, if anyone wants) to reduce the wasteful
amount of buffer space it uses (from 7 to 3 blocks on encrypt, from
6 to 3 blocks on decrypt), but it would take some rework to convert to
crypto_ciph
On Tue, Jun 28, 2016 at 12:15:43PM +0200, Krzysztof Kozlowski wrote:
> Oops:
Thanks, there was a typo where it said k instead of j in the second
loop.
---8<---
This patch resolves a number of issues with the mb speed test
function:
* The tfm is never freed.
* Memory is allocated even when we're
dates):
[ 23.480312] BUG: spinlock bad magic on CPU#5, modprobe/285
[ 23.484918] lock: 0xecab06a8, .magic: , .owner: /-1,
.owner_cpu: 0
[ 23.492374] CPU: 5 PID: 285 Comm: modprobe Not tainted
4.7.0-rc5-next-20160628-3-g28618d2d8c0b #862
[ 23.501724] Hardware nam
This patch resolves a number of issues with the mb speed test
function:
* The tfm is never freed.
* Memory is allocated even when we're not using mb.
* When an error occurs we don't wait for completion for other requests.
* When an error occurs during allocation we may leak memory.
* The test func
On 06/28/2016 10:41 AM, Herbert Xu wrote:
> On Tue, Jun 28, 2016 at 09:23:07AM +0200, Krzysztof Kozlowski wrote:
>> gcc 4.7.3 for ARM on Ubuntu couldn't link tcrypt module because of
>> division of s64:
>> ERROR: "__aeabi_ldivmod" [crypto/tcrypt.ko] undefined!
>>
>> Fixes: 087bcd225c56 ("crypt
On Tue, Jun 28, 2016 at 09:23:07AM +0200, Krzysztof Kozlowski wrote:
> gcc 4.7.3 for ARM on Ubuntu couldn't link tcrypt module because of
> division of s64:
> ERROR: "__aeabi_ldivmod" [crypto/tcrypt.ko] undefined!
>
> Fixes: 087bcd225c56 ("crypto: tcrypt - Add speed tests for SHA multibuffer
On Mon, Jun 27, 2016 at 10:20:03AM -0700, Megha Dey wrote:
> From: Megha Dey
>
> In this patch series, we introduce the multi-buffer crypto algorithm on
> x86_64 and apply it to SHA512 hash computation. The multi-buffer technique
> takes advantage of the 8 data lanes in the AVX2 registers and al
On Tue, Jun 28, 2016 at 09:23:06AM +0200, Krzysztof Kozlowski wrote:
> The recently added test_mb_ahash_speed() has clearly serious coding
> style issues. Try to fix some of them:
> 1. Don't mix pr_err() and printk();
> 2. Don't wrap strings;
> 3. Properly align goto statement in if() block;
> 4. A
On Mon, Jun 27, 2016 at 11:17:40AM +0200, Arnd Bergmann wrote:
> The ARM allmodconfig build currently warngs because of the
> ux500 crypto driver not working well with the jump label
> implementation that we started using for dynamic debug, which
> breaks building with 'gcc -O0':
>
> In file inclu
On Tue, Jun 28, 2016 at 08:41:42AM +0100, Giovanni Cabiddu wrote:
>
> Are you suggesting a different cache of scratch buffers for every
> algorithm implementation or a shared cache shared across all legacy
> scomp algorithms?
One that's shared for every scomp algorithm.
> Would it be ok 128K inst
On Fri, Jun 24, 2016 at 05:26:43PM +0800, Herbert Xu wrote:
> Hmm, I guess we can still keep scomp and use vmalloc until someone
> spends the effort and optimises each algorithm to make them use acomp
> directly.
Ok.
> So I'd still like to move the allocation down into the algorithm.
> That way IP
The recently added test_mb_ahash_speed() has clearly serious coding
style issues. Try to fix some of them:
1. Don't mix pr_err() and printk();
2. Don't wrap strings;
3. Properly align goto statement in if() block;
4. Align wrapped arguments on new line;
5. Don't wrap functions on first argument;
S
gcc 4.7.3 for ARM on Ubuntu couldn't link tcrypt module because of
division of s64:
ERROR: "__aeabi_ldivmod" [crypto/tcrypt.ko] undefined!
Fixes: 087bcd225c56 ("crypto: tcrypt - Add speed tests for SHA multibuffer
algorithms")
Signed-off-by: Krzysztof Kozlowski
---
crypto/tcrypt.c | 4 +
20 matches
Mail list logo
