Re: crypto: ahash - Fix EINPROGRESS notification callback

request > object on the stack which is used to relay EINPROGRESS back to > the original completion function. > > This patch also adds code to preserve the original flags value. > > Cc: <v...@stable.kernel.org> Should that be sta...@vger.kernel.org? > Reported-by: Sa

Re: [PATCH v2] crypto: ahash - Fix EINPROGRESS notification callback

2017-04-10, 17:27:57 +0800, Herbert Xu wrote: > On Mon, Apr 10, 2017 at 11:21:27AM +0200, Sabrina Dubroca wrote: > > > > > Cc: <v...@stable.kernel.org> > > > > Should that be sta...@vger.kernel.org? > > Oops :) > > > > Reported-by:

[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 5/7] crypto: aesni: make AVX2 AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.

[PATCH 0/7] crypto: aesni: provide generic gcm(aes)

6.3Gbps). Sabrina Dubroca (7): crypto: aesni: make non-AVX AES-GCM work with any aadlen crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len crypto: aesni: make AVX AES-GCM work with any aadlen crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len crypto: aesni

[PATCH 3/7] crypto: aesni: make AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 7/7] crypto: aesni: add generic gcm(aes)

Now that the asm side of things can support all the valid lengths of ICV and all lengths of associated data, provide the glue code to expose a generic gcm(aes) crypto algorithm. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_glue.c

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 605726

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> --- arch/x86/crypto/aesni-intel_asm.S

[PATCH crypto] crypto: aesni - fix typo in generic_gcmaes_decrypt

Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Reviewed-by: Stefano Brivio <sbri...@redhat.com> --- arch/x86/crypto/aesni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index 3bf3

[PATCH crypto] crypto: aesni - add wrapper for generic gcm(aes)

) Reported-by: Ilya Lesokhin <il...@mellanox.com> Signed-off-by: Sabrina Dubroca <s...@queasysnail.net> Reviewed-by: Stefano Brivio <sbri...@redhat.com> --- arch/x86/crypto/aesni-intel_glue.c | 66 +++--- 1 file changed, 54 insertions(+), 12 deletions(-)

Re: [RFC crypto v3 0/9] Chelsio Inline TLS

2017-12-20, 17:03:02 +0530, Atul Gupta wrote: > RFC series for Chelsio Inline TLS driver (chtls.ko) > > Driver use the ULP infrastructure to register chtls as Inline TLS ULP. I don't think drivers should be registering their own ULP. TLS offloading should be transparent to userspace, whatever HW

Re: [PATCH v9 crypto 01/12] tls: tls_device struct to register TLS drivers

Hello Atul, One quick note before you start replying: please fix your email client, as you've been told before. Quoting has to add a quoting marker (the '>' character) at the beginning of the line, otherwise it's impossible to separate your reply from the email you're quoting. 2018-03-06,

Re: [PATCH v9 crypto 02/12] ethtool: enable Inline TLS in HW

Since you're saying the driver supports offloading TLS records to the HW, why not call the feature "record offloading"? With, for example, NETIF_F_HW_TLS_RECORD as the feature, and maybe "tls-hw-record" for the ethtool string. This "Inline TLS" name sounds rather like marketing to me.

Re: [PATCH v9 crypto 06/12] cxgb4: LLD driver changes to enable TLS

2018-03-06, 21:09:25 +0530, Atul Gupta wrote: > Read FW capability. Read key area size. Dump the TLS record count. That's not a really helpful commit message. Have a look at other commit messages and try to be more descriptive. It's also not clear if those changes belong together in one patch,

Re: [PATCH v9 crypto 08/12] chtls: Key program

2018-03-06, 21:09:27 +0530, Atul Gupta wrote: [snip] > +static int chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64 val) > +{ > + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk); > + struct sk_buff *skb; > + struct cpl_set_tcb_field *req; > + struct

Re: [PATCH v14 net-next 09/12] crypto: chtls - Inline TLS record Tx

2018-03-29, 21:27:51 +0530, Atul Gupta wrote: > TLS handler for record transmit. > Create Inline TLS work request and post to FW. > Create Inline TLS record CPLs for hardware > > Signed-off-by: Atul Gupta > Signed-off-by: Michael Werner > --- ... >

Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition

2018-03-29, 21:27:50 +0530, Atul Gupta wrote: ... > +static void chtls_pass_accept_request(struct sock *sk, > + struct sk_buff *skb) > +{ ... > + if (chtls_get_module(newsk)) > + goto reject; > + inet_csk_reqsk_queue_added(sk); > +

Re: [PATCH v13 net-next 02/12] ethtool: enable Inline TLS in HW

io.com> > Reviewed-by: Sabrina Dubroca <sdubr...@redhat.com> uh, what? I definitely didn't give my "Reviewed-by" for any of these patches. Please never do that again. -- Sabrina

Re: [PATCH v11 crypto 06/12] crypto: chtls - structure and macro for Inline TLS

2018-03-16, 21:07:35 +0530, Atul Gupta wrote: [...] > +#define SOCK_INLINE (31) [...] > +static inline int csk_flag(const struct sock *sk, enum csk_flags flag) > +{ > + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk); > + > + if (!sock_flag(sk, SOCK_INLINE)) > +