On 08/20/2018 07:46 PM, Eric Biggers wrote:
> On Wed, Aug 15, 2018 at 09:35:03AM -0700, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
>> git tree: linux-next
>> console output: https://syzkaller
On 08/10/2018 12:12 PM, Jeff Lien wrote:
> This patch provides a performance improvement for the CRC16 calculations done
> in read/write
> workloads using the T10 Type 1/2/3 guard field. For example, today with
> sequential write
> workloads (one thread/CPU of IO) we consume 100% of the CPU beca
know who to Cc on patches.
>
> Eric
>
Herbert,
Can you pull in the patch below to update MAINTAINERS for sha multibuffer?
Tim
>From 884095fccd36d2de8c6edfe6f4d60ab4a1b9339b Mon Sep 17 00:00:00 2001
From: Tim Chen
Date: Mon, 29 Jan 2018 09:22:41 -0800
Subject: [PATCH] x86/crypto: Des
On 01/24/2018 07:10 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> The HASH_FIRST flag is never set. Remove it.
>
> Signed-off-by: Eric Biggers
> ---
> arch/x86/crypto/sha1-mb/sha1_mb.c | 28 +++-
> arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 8 +++-
> 2 files c
On 01/24/2018 07:09 PM, Eric Biggers wrote:
> From: Eric Biggers
>
> There is no need for ahash_mcryptd_{update,final,finup,digest}(); we
> should just call crypto_ahash_*() directly.
>
This clean up could have been done when we made sha1-mb async. Looks
reasonable.
Ack
d.
However, flush is done on the non performance critical path so
I don't expect this will be an issue to performance.
Thanks.
Tim
Acked-by: Tim Chen
>
> Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2")
> Reported-by: Josh Poimboeuf
&g
On 08/29/2017 11:05 AM, Josh Poimboeuf wrote:
> Using RBP as a temporary register breaks frame pointer convention and
> breaks stack traces when unwinding from an interrupt in the crypto code.
>
> Use R11 instead of RBP. Since R11 isn't a callee-saved register, it
> doesn't need to be saved and r
On 08/02/2017 03:39 AM, Jan Stancek wrote:
> On 08/02/2017 02:38 AM, Megha Dey wrote:
>> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
>> reading ahead beyond its intended data, and causing a crash if the next
>> block is beyond page boundary:
>> http://marc.info/?l=linux-cryp
On 07/17/2017 10:41 PM, Herbert Xu wrote:
> On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
>>
>> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
>> +struct mcryptd_alg_cstate *cstate,
>> +int err)
>> +{
>> +
On 06/23/2017 01:48 AM, Jan Stancek wrote:
>
>
> - Original Message -
>> On Wed, May 24, 2017 at 08:46:57AM -0400, Jan Stancek wrote:
>>>
>>>
>>> - Original Message -
Hi,
I'm seeing rare crashes during NFS cthon with krb5 auth. After
some digging I arrived at p
On Tue, 2017-04-25 at 12:18 +0300, Dan Carpenter wrote:
> We recently added some new locking but missed the unlocks on these
> error paths in sha512_ctx_mgr_submit().
Thanks for catching this issue.
Acked-by: Tim Chen
>
> Fixes: c459bd7beda0 ("crypto: sha512-mb - Protect
On Sat, 2017-02-11 at 18:50 +0800, Herbert Xu wrote:
> On Wed, Feb 01, 2017 at 10:45:02AM -0800, Tim Chen wrote:
> >
> >
> > One theory that Mehga and I have is that perhaps the flusher
> > and regular computaion updates are stepping on each other.
> > Can you t
On Thu, 2017-02-02 at 11:58 +0100, Dmitry Vyukov wrote:
> On Wed, Feb 1, 2017 at 7:45 PM, Tim Chen wrote:
> >
> > On Tue, Jan 31, 2017 at 02:16:31PM +0100, Dmitry Vyukov wrote:
> > >
> > > Hello,
> > >
> > > I am getting the following repor
> ---[ end trace 139fd4cda5dfe2c4 ]---
>
Dmitry,
One theory that Mehga and I have is that perhaps the flusher
and regular computaion updates are stepping on each other.
Can you try this patch and see if it helps?
Tim
--->8---
From: Tim Chen
Subject: [PATCH] crypto/sha512-mb: Protect s
On Tue, 2017-01-31 at 14:16 +0100, Dmitry Vyukov wrote:
> Hello,
>
> I am getting the following reports with low frequency while running
> syzkaller fuzzer. Unfortunately they are not reproducible and happen
> in a background thread, so it is difficult to extract any context on
> my side. I see on
=linux-crypto-vger&m=148063683310477&w=2
Cc: sta...@vger.kernel.org
Reported-by: Mikulas Patocka
Signed-off-by: Tim Chen
---
crypto/mcryptd.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index 94ee44a..c207458 100644
On Mon, 2016-12-05 at 08:50 -0800, Tim Chen wrote:
> On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote:
> >
> > On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote:
> > >
> > >
> > > Algorithms not compatible with mcryptd could be spawned by mc
On Mon, 2016-12-05 at 20:34 +0800, Herbert Xu wrote:
> On Fri, Dec 02, 2016 at 04:15:21PM -0800, Tim Chen wrote:
> >
> > Algorithms not compatible with mcryptd could be spawned by mcryptd
> > with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)"
> >
CRYPT is being added to mcryptd compatible
algorithms' cra_flags. The compatability is checked when mcryptd spawn
off an algorithm.
Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2
Cc: sta...@vger.kernel.org
Reported-by: Mikulas Patocka
Tested-by: Megha Dey
Signe
On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote:
> Hi
>
> There is a bug in mcryptd initialization.
>
> This is a test module that tries various hash algorithms. When you load
> the module with "insmod test.ko 'alg=mcryptd(md5)'", the machine crashes.
>
> Mikulas
>
>
Mikulas,
Can y
On Thu, 2016-12-01 at 23:06 -0800, Eric Biggers wrote:
> On Thu, Dec 01, 2016 at 05:47:02PM -0800, Tim Chen wrote:
> >
> > On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote:
> > >
> > > Hi
> > >
> > > There is a bug in mcryptd initializa
On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote:
> Hi
>
> There is a bug in mcryptd initialization.
>
> This is a test module that tries various hash algorithms. When you load
> the module with "insmod test.ko 'alg=mcryptd(md5)'", the machine crashes.
I don't think your test setup is r
Tucker
Acked-by: Tim Chen
> ---
> arch/x86/crypto/sha1-mb/sha1_mb.c | 2 +-
> arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 2 +-
> arch/x86/crypto/sha256-mb/sha256_mb.c | 2 +-
> arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 2 +-
> arch/x86/crypto/sha512-mb/sha512_m
On Tue, 2016-10-04 at 16:10 +0200, Stephan Mueller wrote:
> Am Dienstag, 4. Oktober 2016, 00:25:07 CEST schrieb Dey, Megha:
>
> Hi Megha,
>
> >
> >
> > >
> > > Hi Stephan,
> > >
> > > Your test code initialized the completion structure incorrectly, that led
> > > to the missing completion fro
On Fri, 2016-08-12 at 06:28 -0400, Xiaodong Liu wrote:
> Signed-off-by: Xiaodong Liu
> ---
> arch/x86/crypto/sha512-mb/sha512_mb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c
> b/arch/x86/crypto/sha512-mb/sha512_mb.c
> index
On Fri, 2016-08-12 at 06:24 -0400, Xiaodong Liu wrote:
> 1. fix ctx pointer
> Use req_ctx which is the ctx for the next job that have
> been completed in the lanes instead of the first
> completed job rctx, whose completion could have been
> called and released.
> 2. fix digest copy
> Use XMM regis
On Mon, 2016-07-18 at 10:59 +0200, Pavel Machek wrote:
> On Fri 2016-07-08 10:19:26, Linus Torvalds wrote:
> >
> > [ rare comment rant. I think I'll do this once, and then ignore the
> > discussion ]
> >
> > On Fri, Jul 8, 2016 at 9:45 AM, Herbert Xu
> > wrote:
> > >
> > >
> > > Nack. As I
On Sat, 2016-07-09 at 00:45 +0800, Herbert Xu wrote:
> On Fri, Jul 08, 2016 at 09:28:03AM -0700, Tim Chen wrote:
> >
> >
> > Sorry I was on vacation and didn't get to respond earlier.
> > Let's switch the above from | to || so the code logic is
> >
was on vacation and didn't get to respond earlier.
Let's switch the above from | to || so the code logic is
clearer. Also clean up various multi-line comment style
inconsistencies in patch below.
Thanks.
Tim
---
From: Tim Chen
Subject: [PATCH] crypto: Cleanup sha multi-buffer code t
On Wed, 2016-06-29 at 10:05 -0700, H. Peter Anvin wrote:
> On 06/29/16 07:42, Dan Carpenter wrote:
> >
> > >
> > > >
> > > > and | behave basically the same here but || is intended. It causes a
> > static checker warning to mix up bitwise and logical operations.
> >
> > Signed-off-by: Dan Carp
have been completed in the lanes
instead of the first completed job rctx, whose
completion could have been called and released.
Should be propagated back to stable release.
Acked-by: Tim Chen
Tim
>
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
due to this. To ensure
> sanity, adding the missing _args_digest offset to the sha1_mb_mgr_submit.S.
>
Thanks for cleaning this up.
Acked-by: Tim Chen
> Signed-off-by: Megha Dey
> ---
> arch/x86/crypto/sha-mb/sha1_mb_mgr_submit_avx2.S | 2 +-
> 1 file changed, 1 insertion(+)
Herbert,
There are some ahash algorithms like x86's sha1-mb and
ghash that failed to register because of the newly added
check of non-zero statesize from commit 8996eafd. But
since there are algorithms that do not implement an import or
export, there is no state required for them. Wonder if the
On Sat, 2015-12-12 at 13:48 +0800, Herbert Xu wrote:
> On Fri, Dec 11, 2015 at 08:54:40AM -0800, Tim Chen wrote:
> > Direct call I assume have less overhead. Let me think about
>
> static inline int crypto_ablkcipher_encrypt(struct ablkcipher_request *req)
> {
> struc
On Fri, 2015-12-11 at 11:23 +0800, Herbert Xu wrote:
> On Thu, Dec 10, 2015 at 08:39:45AM -0800, Tim Chen wrote:
> >
> > The inner cipher is called synchronously from the outer layer
> > async cipher algorithm in cbc_mb_async_ablk_decrypt via
> >
> > err
On Thu, 2015-12-10 at 09:45 +0800, Herbert Xu wrote:
> On Wed, Dec 09, 2015 at 09:23:14AM -0800, Tim Chen wrote:
> >
> > This is an internal algorithm. We are indeed casting the request
> > to the outer ablkcipher request when we do the async cipher walk.
>
> The q
On Wed, 2015-12-09 at 10:52 +0800, Herbert Xu wrote:
> On Wed, Dec 02, 2015 at 12:02:45PM -0800, Tim Chen wrote:
> >
> > +/*
> > + * CRYPTO_ALG_ASYNC flag is passed to indicate we have an ablk
> > + * scatter-gather walk.
> > + */
> > +
>
t job in a completed state.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416
On Tue, 2015-12-01 at 09:19 -0800, Tim Chen wrote:
> On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote:
> > On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote:
> > >
> > > On the decrypt path, we don't need to use multi-buffer algorithm
> > &g
This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.
Encryption of 8 data streams of a key size are done simultaneously.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 835
3 files changed, 858 insertions(+)
create mode 100644 arch/x86/crypto/aes
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125
odify blkcipher_walk for multibuffer cipher
v2
1. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Tim Chen (5):
crypto: Multi-buffer encryption infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AE
see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
crypto/Kconfig | 16 +++
crypto/mcryptd.c | 256 ++-
include/crypto
On Thu, 2015-11-26 at 16:49 +0800, Herbert Xu wrote:
> On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote:
> >
> > On the decrypt path, we don't need to use multi-buffer algorithm
> > as aes-cbc decrypt can be parallelized inherently on a single
> > request
On Tue, 2015-11-24 at 17:47 +0800, Herbert Xu wrote:
> On Thu, Nov 19, 2015 at 02:15:40PM -0800, Tim Chen wrote:
> >
> > This patch introduces the multi-buffer job manager which is responsible
> > for submitting scatter-gather buffers from several AES CBC jobs
> > to
see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
crypto/Kconfig | 16 +++
crypto/mcryptd.c | 256 ++-
include/crypto
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125
This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.
Encryption of 8 data streams of a key size are done simultaneously.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 827
include/crypto/mcryptd.h| 2 +-
4 files changed, 851
t job in a completed state.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416
e cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Tim Chen (5):
crypto: Multi-buffer encryptioin infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8 encry
On Thu, 2015-11-19 at 08:12 +0800, Herbert Xu wrote:
> On Wed, Nov 18, 2015 at 07:58:56AM -0800, Tim Chen wrote:
> >
> > IPSec will invoke this multi-buffer encrypt with async request.
> > The work is done in crypto daemon, so it wouldn't be in atomic
> > con
On Wed, 2015-11-18 at 13:06 +0800, Herbert Xu wrote:
> On Tue, Nov 17, 2015 at 04:30:14PM -0800, Tim Chen wrote:
> > On Wed, 2015-11-18 at 08:07 +0800, Herbert Xu wrote:
> > > On Tue, Nov 17, 2015 at 02:59:29PM -0800, Tim Chen wrote:
> > > >
> > > > Herb
On Wed, 2015-11-18 at 08:07 +0800, Herbert Xu wrote:
> On Tue, Nov 17, 2015 at 02:59:29PM -0800, Tim Chen wrote:
> >
> > Herbert, would you prefer me to use ablkcipher scatter walk instead,
> > assuming the overhead of both walk are about the same?
>
> Well since y
On Tue, 2015-11-17 at 21:06 +0800, Herbert Xu wrote:
> On Thu, Oct 29, 2015 at 03:21:03PM -0700, Tim Chen wrote:
> >
> > c) Add support to crypto scatterwalk support that can sleep during
> > encryption operation, as we may have buffers for jobs in data lanes
> > that
This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.
Encryption of 8 data streams of a key size are done simultaneously.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
crypto/Kconfig | 16 +++
crypto/blkcipher.c | 29 -
crypto/mcryptd.c | 256 ++-
crypto/scatterwalk.c | 7 ++
include/crypto/algapi.h | 1
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 812
3 files changed, 835 insertions(+)
create mode 100644 arch/x86/crypto/aes
t job in a completed state.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416
saw a throughput increase of up to
5.8x under optimal conditions when we have fully loaded encryption jobs
filling up all the data lanes.
Change Log:
v2
1. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Tim Chen (5):
crypto:
On Thu, 2015-10-29 at 09:19 -0700, Tim Chen wrote:
> On Thu, 2015-10-29 at 03:03 +0100, Stephan Mueller wrote:
> > Am Mittwoch, 28. Oktober 2015, 14:19:29 schrieb Tim Chen:
> >
> > Hi Tim,
> >
> > >+
> > >+ /* check for depen
On Thu, 2015-10-29 at 03:03 +0100, Stephan Mueller wrote:
> Am Mittwoch, 28. Oktober 2015, 14:19:29 schrieb Tim Chen:
>
> Hi Tim,
>
> >+
> >+/* check for dependent cpu features */
> >+if (!cpu_has_aes) {
> >+pr_err("aes_cbc_mb_mod_init
On Thu, 2015-10-29 at 08:51 +0100, LABBE Corentin wrote:
> On Fri, Oct 16, 2015 at 09:04:58AM -0700, Tim Chen wrote:
> > On Wed, 2015-10-14 at 21:15 +0200, LABBE Corentin wrote:
> > > The sha x86 crypto code use two define for the same thing:
> > > NUM_SHA1_DIGEST_W
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 815
3 files changed, 838 insertions(+)
create mode 100644 arch/x86/crypto/aes
This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.
Encryption of 8 data streams of a key size are done simultaneously.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb
the oldest job in a completed state.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 145 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 222 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 416
Signed-off-by: Tim Chen
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 96 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 131
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 270 +
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 125
: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
crypto/Kconfig | 16 +++
crypto/blkcipher.c | 29 -
crypto/mcryptd.c | 256 ++-
crypto/scatterwalk.c | 7 ++
include/crypto/algapi.h | 1 +
include
.
By using this technique, we saw a throughput increase of up to
5.8x under optimal conditions when we have fully loaded encryption jobs
filling up all the data lanes.
Tim Chen (5):
crypto: Multi-buffer encryptioin infrastructure support
crypto: AES CBC multi-buffer data structures
crypto
On Wed, 2015-10-14 at 21:15 +0200, LABBE Corentin wrote:
> The sha x86 crypto code use two define for the same thing:
> NUM_SHA1_DIGEST_WORDS and SHA1_DIGEST_LENGTH
> Replace them by SHA1_DIGEST_SIZE/4
Thanks. Acked-by: Tim Chen
>
> Signed-off-by: LABBE Corentin
--
To unsubs
On Mon, 2015-09-21 at 22:02 +0800, Herbert Xu wrote:
> Hi Tim:
>
> On Fri, Sep 18, 2015 at 09:12:01AM -0700, Tim Chen wrote:
> >
> > It seems like Thomas has already merged the cpu id patch upstream.
> > http://git.kernel.org/cgit/linux/kernel
On Fri, 2015-09-18 at 23:17 +0800, Herbert Xu wrote:
> On Fri, Sep 18, 2015 at 10:36:07PM +0800, kbuild test robot wrote:
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
> > master
> > head: dcde21287f931b6cee61825306db6a5665566f66
> > commit: a3476db1b
On Thu, 2015-09-17 at 19:07 +0200, Dominik Dingel wrote:
> On Thu, 17 Sep 2015 18:45:00 +0200
> Paolo Bonzini wrote:
>
> >
> >
> > On 17/09/2015 18:27, Dominik Dingel wrote:
> > > + preempt_disable();
> > > + solo = single_task_running();
> > > +
: Tim Chen
---
arch/x86/crypto/sha512_ssse3_glue.c | 249 +---
1 file changed, 204 insertions(+), 45 deletions(-)
diff --git a/arch/x86/crypto/sha512_ssse3_glue.c
b/arch/x86/crypto/sha512_ssse3_glue.c
index 2edad7b..0dfe9a2 100644
--- a/arch/x86/crypto
maintain.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha1_ssse3_glue.c | 324 +-
1 file changed, 250 insertions(+), 74 deletions(-)
diff --git a/arch/x86/crypto/sha1_ssse3_glue.c
b/arch/x86/crypto/sha1_ssse3_glue.c
index 98be8cc..c934197 100644
--- a/arch/x86
maintain.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha256_ssse3_glue.c | 331 ++--
1 file changed, 281 insertions(+), 50 deletions(-)
diff --git a/arch/x86/crypto/sha256_ssse3_glue.c
b/arch/x86/crypto/sha256_ssse3_glue.c
index 9c7b22c..863e2f6 100644
--- a/arch
27;ve also performed clean up of the glue code to make them easier to
maintain.
Thanks.
Tim
Pre-req patch series:
[1] https://lkml.org/lkml/2015/9/10/554
Tim Chen (3):
crypto: [sha] Restructure x86 sha1 glue code to expose all the
available sha1 transforms
crypto: [sha] Restructure x86 s
On Fri, 2015-09-11 at 12:15 -0700, David Miller wrote:
> From: Tim Chen
> Date: Fri, 11 Sep 2015 11:49:32 -0700
>
> > Still, why would some kernel module specifically not want to
> > use the fastest HW implementation, and explicitly ask for
> > a slower driver?
>
On Fri, 2015-09-11 at 19:02 +0200, Stephan Mueller wrote:
> Am Donnerstag, 10. September 2015, 17:04:31 schrieb Tim Chen:
>
> Hi Tim,
> >
> >Is there a scenario you can think of
> >when a lower performing sha1 transform needs to
> >be exposed as a separate dri
On Fri, 2015-09-11 at 00:52 +0200, Stephan Mueller wrote:
> Am Donnerstag, 10. September 2015, 15:27:20 schrieb Tim Chen:
>
> Hi Tim,
>
> >This patch adds the glue code to detect and utilize the Intel SHA
> >extensions optimized SHA1 and SHA256 update transforms when ava
This patch includes the Intel SHA Extensions optimized implementation
of SHA-256 update function. This function has been tested on Broxton
platform and measured a speed up of 3.6x over the SSSE3 implementiation
for 4K blocks.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
This patch includes the Intel SHA Extensions optimized implementation
of SHA-1 update function. This function has been tested on Broxton
platform and measured a speed up of 3.6x over the SSSE3 implementiation
for 4K blocks.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
This patch provides the configuration and build support to
include and build the optimized SHA1 and SHA256 update transforms
for the kernel's crypto library.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/Makefile| 6 --
arch/x86/crypto/Makefile
This patch adds the glue code to detect and utilize the Intel SHA
extensions optimized SHA1 and SHA256 update transforms when available.
This code has been tested on Broxton for functionality.
Originally-by: Chandramouli Narayanan
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha1_ssse3_glue.c
3.pdf
Pre-req patches:
[1] [PATCH] sha: Enable cpuid check for Intel SHA extensions implementations
http://marc.info/?l=linux-kernel&m=144019424304089&w=2
[2] [Patch] x86/insn: perf tools: Add new SHA instructions
http://marc.info/?l=linux-kernel&m=144119645000679&w=2
Tim Che
On Fri, 2015-05-29 at 08:29 +0800, Herbert Xu wrote:
> On Thu, May 28, 2015 at 02:23:33PM -0700, Tim Chen wrote:
> >
> > Quick question. When src and dst are different, the above code
> > leave space for the assoc data in dst. However, I don't think we copy
> >
On Thu, 2015-05-28 at 22:04 +0800, Herbert Xu wrote:
> @@ -1011,55 +966,55 @@ static int __driver_rfc4106_encrypt(struct
> aead_request *req)
> *(iv+4+i) = req->iv[i];
> *((__be32 *)(iv+12)) = counter;
>
> - if ((sg_is_last(req->src)) && (sg_is_last(req->assoc))) {
> +
On Sat, 2015-04-25 at 23:33 +0900, Akinobu Mita wrote:
> This introduces crc_t10dif_update() which enables to calculate CRC
> for a block which straddles multiple SG elements by calling multiple
> times.
>
> Signed-off-by: Akinobu Mita
> Cc: Tim Chen
> Cc: Herbert Xu
&
On Fri, 2015-03-13 at 23:13 +0200, Ameen Ali wrote:
> fixing a syntax-error .
>
> Signed-off-by : Ameen Ali
> ---
> arch/x86/crypto/sha-mb/sha1_mb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c
> b/arch/x86/crypto/sha-mb/sha1_mb.c
>
On Mon, 2015-01-12 at 17:06 +1100, Herbert Xu wrote:
> On Sun, Jan 11, 2015 at 11:48:08PM -0500, Timothy McCaffrey wrote:
> >
> > This patch has been tested with Sandy Bridge and Haswell processors. With
> > 128
> > bit keys and input buffers > 512 bytes a slight performance degradation was
> > n
S_IDLE;
> return ctx;
> }
>
Agree. This NULL pointer check is not necessary.
Acked-by: Tim Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2014-08-01 at 22:18 +0800, Herbert Xu wrote:
> On Wed, Jul 23, 2014 at 09:07:45AM -0700, Tim Chen wrote:
> > On Wed, 2014-07-23 at 21:09 +0800, Herbert Xu wrote:
> > > On Thu, Jul 10, 2014 at 04:18:08PM -0700, Tim Chen wrote:
> > > > For the special case wh
This patch introduces the data structures and prototypes of functions
needed for computing SHA1 hash using multi-buffer. Included are the
structures of the multi-buffer SHA1 job, job scheduler in C and x86
assembly.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_datastruct.S
This patch introduces the routines used to submit and flush buffers
belonging to SHA1 crypto jobs to the SHA1 multibuffer algorithm. It is
implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 327
process can take
advantgae of the available cpu cycles to a make decision to continue
processing the existing accumulated work to minimize delay,
otherwise it will yield.
Signed-off-by: Tim Chen
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 12
2 files changed, 13 insertions
e the deadline of maximum latency of a SHA1 crypto job.
The SHA1 multi-buffer crypto algorithm is defined and initialized in
this patch.
Signed-off-by: Tim Chen
---
arch/x86/crypto/Makefile | 2 +
arch/x86/crypto/sha-mb/Makefile | 11 +
arch/x86/crypto/sha-mb/sha1_mb.c
This patch introduces the assembly routines to do SHA1 computation on
buffers belonging to serveral jobs at once. The assembly routines are
optimized with AVX2 instructions that have 8 data lanes and using AVX2
registers.
Signed-off-by: Tim Chen
---
arch/x86/crypto/sha-mb/sha1_x8_avx2.S | 472
of SIMD instructions to do crypto computation on several
buffers simultaneously.
The multi-buffer crypto daemon is also responsbile for flushing the
remaining buffers to complete the computation if no new buffers arrive
for a while.
Signed-off-by: Tim Chen
---
crypto/Kconfig
1 - 100 of 267 matches
Mail list logo
