Re: [PATCH v13 net-next 01/12] tls: support for Inline tls record

On 3/27/2018 11:53 PM, Stefano Brivio wrote: > On Tue, 27 Mar 2018 23:06:30 +0530 > Atul Gupta wrote: > >> +static struct tls_context *create_ctx(struct sock *sk) >> +{ >> +struct inet_connection_sock *icsk = inet_csk(sk); >> +struct tls_context *ctx; >> + >> +

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

On 3/27/2018 11:12 PM, Stefano Brivio wrote: > On Tue, 27 Mar 2018 23:06:37 +0530 > Atul Gupta wrote: > >> Exchange messages with hardware to program the TLS session >> CPL handlers for messages received from chip. >> >> Signed-off-by: Atul Gupta

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

On 3/28/2018 2:14 AM, Sabrina Dubroca wrote: > 2018-03-27, 23:06:31 +0530, Atul Gupta wrote: >> Ethtool option enables TLS record offload on HW, user >> configures the feature for netdev capable of Inline TLS. >> This allows user to define custom sk_prot for Inline TLS sock >> >> Signed-off-by:

[PATCH v15 9/9] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko

[PATCH v15 2/9] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan

[PATCH v15 0/9] Add io{read|write}64 to io-64-atomic headers

This is v14 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

[PATCH v15 7/9] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v15 1/9] iomap: Use non-raw io functions for io{read|write}XXbe

Fix an asymmetry in the io{read|write}XXbe functions in that the big-endian variants make use of the raw io accessors while the little-endian variants use the regular accessors. Some architectures implement barriers to order against both spinlocks and DMA accesses and for these case, the

[PATCH v15 6/9] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v15 8/9] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v15 3/9] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by:

[PATCH v15 5/9] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v15 4/9] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

My name is Charles Koch Foundation,

My name is Charles Koch Foundation, A philanthropist the CEO and Chairman of the Charles Koch Foundation Charitable Foundation, one of the largest private foundations in the world. I believe strongly in‘giving while living' I had one idea that never changed in my mind - that you should use your

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

2018-03-27, 23:06:31 +0530, Atul Gupta wrote: > Ethtool option enables TLS record offload on HW, user > configures the feature for netdev capable of Inline TLS. > This allows user to define custom sk_prot for Inline TLS sock > > Signed-off-by: Atul Gupta > Reviewed-by:

HI

-- Greeting, once again is me Lucy Boston this is twice am contacting you please is very urgent respond to me for more details through my. Email: dr.lucybos...@gmail.com

Re: [PATCH v13 net-next 01/12] tls: support for Inline tls record

On Tue, 27 Mar 2018 23:06:30 +0530 Atul Gupta wrote: > +static struct tls_context *create_ctx(struct sock *sk) > +{ > + struct inet_connection_sock *icsk = inet_csk(sk); > + struct tls_context *ctx; > + > + /* allocate tls context */ > + ctx =

Re: [PATCH v13 net-next 07/12] crypto: chtls - Program the TLS session Key

On Tue, 27 Mar 2018 23:06:36 +0530 Atul Gupta wrote: > +static void __set_tcb_field(struct sock *sk, struct sk_buff *skb, u16 word, > + u64 mask, u64 val, u8 cookie, int no_reply) > +{ > + struct chtls_sock *csk =

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

On Tue, 27 Mar 2018 23:06:38 +0530 Atul Gupta wrote: > +static u8 tcp_state_to_flowc_state(u8 state) > +{ > + u8 ret = FW_FLOWC_MNEM_TCPSTATE_ESTABLISHED; > + > + switch (state) { > + case TCP_ESTABLISHED: > + ret =

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

On Tue, 27 Mar 2018 23:06:37 +0530 Atul Gupta wrote: > Exchange messages with hardware to program the TLS session > CPL handlers for messages received from chip. > > Signed-off-by: Atul Gupta > Signed-off-by: Michael Werner >

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

On Tue, 27 Mar 2018 23:06:38 +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 v13 net-next 07/12] crypto: chtls - Program the TLS session Key

On Tue, 27 Mar 2018 23:06:36 +0530 Atul Gupta wrote: > Initialize the space reserved for storing the TLS keys, > get and free the location where key is stored for the TLS > connection. > Program the Tx and Rx key as received from user in > struct

[PATCH v13 net-next 10/12] crypto: chtls - Inline TLS record Rx

handler for record receive. plain text copied to user buffer Signed-off-by: Atul Gupta Signed-off-by: Michael Werner --- drivers/crypto/chelsio/chtls/chtls_io.c | 592 1 file changed, 592 insertions(+) diff --git

[PATCH v13 net-next 12/12] crypto: chtls - Makefile Kconfig

Entry for Inline TLS as another driver dependent on cxgb4 and chcr Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/Kconfig| 11 +++ drivers/crypto/chelsio/Makefile | 1 + drivers/crypto/chelsio/chtls/Makefile | 4 3 files changed, 16

[PATCH v13 net-next 11/12] crypto: chtls - Register chtls with net tls

Register chtls as Inline TLS driver, chtls is ULD to cxgb4. Setsockopt to program (tx/rx) keys on chip. Support AES GCM of key size 128. Support both Inline Rx and Tx. Signed-off-by: Atul Gupta Reviewed-by: Casey Leedom Reviewed-by: Michael Werner

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

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 Reviewed-by: Stefano Brivio ---

[PATCH v13 net-next 07/12] crypto: chtls - Program the TLS session Key

Initialize the space reserved for storing the TLS keys, get and free the location where key is stored for the TLS connection. Program the Tx and Rx key as received from user in struct tls12_crypto_info_aes_gcm_128 and understood by hardware. added socket option TLS_RX Signed-off-by: Atul Gupta

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

Exchange messages with hardware to program the TLS session CPL handlers for messages received from chip. Signed-off-by: Atul Gupta Signed-off-by: Michael Werner Reviewed-by: Sabrina Dubroca Reviewed-by: Stefano Brivio

[PATCH v13 net-next 04/12] cxgb4: LLD driver changes to support TLS

Read the Inline TLS capability from firmware. Determine the area reserved for storing the keys Dump the Inline TLS tx and rx records count. Signed-off-by: Atul Gupta Reviewed-by: Michael Werner Reviewed-by: Casey Leedom ---

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

Ethtool option enables TLS record offload on HW, user configures the feature for netdev capable of Inline TLS. This allows user to define custom sk_prot for Inline TLS sock Signed-off-by: Atul Gupta Reviewed-by: Sabrina Dubroca ---

[PATCH v13 net-next 05/12] crypto: chcr - Inline TLS Key Macros

Define macro for programming the TLS Key context Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chcr_algo.h | 42 + drivers/crypto/chelsio/chcr_core.h | 55 +- 2 files changed, 96 insertions(+), 1

[PATCH v13 net-next 06/12] crypto: chtls - structure and macro for Inline TLS

Define Inline TLS state, connection management info. Supporting macros definition. Signed-off-by: Atul Gupta Reviewed-by: Sabrina Dubroca Reviewed-by: Michael Werner --- drivers/crypto/chelsio/chtls/chtls.h| 483

[PATCH v13 net-next 03/12] cxgb4: Inline TLS FW Interface

Key area size in hw-config file. CPL struct for TLS request and response. Work request for Inline TLS. Signed-off-by: Atul Gupta Reviewed-by: Casey Leedom --- drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 122 ++-

[PATCH v13 net-next 01/12] tls: support for Inline tls record

Facility to register Inline TLS drivers to net/tls. Setup TLS_HW_RECORD prot to listen on offload device. Cases handled - Inline TLS device exists, setup prot for TLS_HW_RECORD - Atleast one Inline TLS exists, sets TLS_HW_RECORD. - If non-inline device establish connection, move to TLS_SW_TX

[PATCH v13 net-next 00/12] Chelsio Inline TLS

"Thank you, Stefano, Sabrina, Dave W. and everyone for reviewing the series." "Dave, this should apply clean on net-next tree and I think it is ready to merge". Series for Chelsio Inline TLS driver (chtls) Use tls ULP infrastructure to register chtls as Inline TLS driver. Chtls use TCP Sockets

RE: [PATCH] omap-aes - fix crypto cleanup

Hi Tero, > Also, I think this patch should be split up in two, as there are two > issues you are fixing; the bad pointer issue (which I think you only > fixed partially, also the in->sgl has similar problem), and the missing > output IVI. Why is this needed btw, I have never faced the requirement

RE: [PATCH] omap-crypto - fix kernel oops and output buffer update

Hi Tero, > I have a couple of additional comments, but can't add them as the patch > content is an attachment (like, I would not add the WARN_ON.) Overall, > the issue you have found is a legitimate problem, and should be fixed. I have used WARN_ON() to have some very visible output, I agree it

Re: [RESEND] SHASH_DESC_ON_STACK macro

On Fri, Mar 23, 2018 at 02:09:46PM -0500, Gustavo A. R. Silva wrote: > > Hi Herbert, > > There is an ongoing effort to remove all VLAs from the code base [1] and > while working on that I came across the following macro at > include/crypto/hash.h:154: > > #define SHASH_DESC_ON_STACK(shash, ctx)

RE: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Hi Milan, I will run veritysetup test on next version of these patches and contact you about verity-compat-test testsuits. Thank you, Yael -Original Message- From: Milan Broz Sent: Tuesday, 27 March 2018 11:05 To: Eric Biggers ; Yael Chemla

RE: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Hi Eric, Thanks for the detailed feedback, I'll have a look at how dm-crypt avoid dynamic allocation per-bio, and also do forward error correction tests. Yael -Original Message- From: Eric Biggers Sent: Tuesday, 27 March 2018 9:55 To: Yael Chemla

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Mike and others, did anyone even try to run veritysetup tests? We have verity-compat-test in our testsuite, is has even basic FEC tests included. We just added userspace verification of FEC RS codes to compare if kernel behaves the same. I tried to apply three last dm-verity patches from

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

[+Cc linux-crypto] Hi Yael, On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote: > Allow parallel processing of bio blocks by moving to async. completion > handling. This allows for better resource utilization of both HW and > software based hash tfm and therefore better performance

Re: [PATCH 07/10] kbuild: clean up *-asn1.[ch] patterns from top-level Makefile

+CC linux-crypto@vger.kernel.org No functional change, though. 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > Clean up these patterns from the top Makefile to omit 'clean-files' > in each Makefile. > > Signed-off-by: Masahiro Yamada

Re: [PATCH 08/10] kbuild: rename *-asn1.[ch] to *.asn.[ch]

+CC linux-crypto@vger.kernel.org No functional change, though. (I fixed up the subject.) 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > Our convention is to distinguish file types by suffixes with a period > as a separator. > > *-asn1.[ch] is a different pattern

Re: [PATCH 06/10] .gitignore: move *-asn1.[ch] patterns to the top-level .gitignore

+CC linux-crypto@vger.kernel.org No functional change, though. 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > These are common patterns where source files are parsed by the > asn1_compiler. > > Signed-off-by: Masahiro Yamada > --- >