Re: [PATCH v15 net-next 00/12] Chelsio Inline TLS

From: Atul Gupta Date: Sat, 31 Mar 2018 21:41:51 +0530 > Series for Chelsio Inline TLS driver (chtls) Series applied, thank you.

Re: [PATCH v2 net-next 0/6] TLS Rx

From: Dave Watson Date: Thu, 22 Mar 2018 10:09:44 -0700 > TLS tcp socket RX implementation, to match existing TX code. Looks great Dave. Applied, and once my build tests finish I'll push this out to net-next. In some of the new functions, reverse christmas tree ordering of

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

From: Atul Gupta Date: Sun, 18 Mar 2018 14:30:30 + > Hi Dave/Herbert, > > This series is against crypto tree, should I submit two patch series: > 1. netdev specific changes against net-next tree? > 2. crypto changes against crypto tree? Herbert, is it OK for this

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

From: Atul Gupta Date: Fri, 16 Mar 2018 21:06:22 +0530 > Series for Chelsio Inline TLS driver (chtls) This series doesn't even come close to applying to the net-next tree, please respin. Thank you.

Re: [crypto v8 04/12] chtls: structure and macro definiton

From: Atul Gupta Date: Thu, 1 Mar 2018 11:19:35 +0530 > + __u8 reneg_to_write_rx; > + __u8 protocol; You should use "u8" rather than "__u8" except in UAPI headers which this file is not. Please audit your entire patch series for this issue. Thank you.

Re: [Crypto v7 00/12] Chelsio Inline TLS

If nobody is going to actually review these changes for substance and give real feedback, I will just keep picking the patch series apart with coding style nitpicks until somebody does. You have been warned :-)

Re: [Crypto v6 03/12] tls: support for inline tls

From: Atul Gupta Date: Mon, 19 Feb 2018 12:19:41 +0530 > + struct net_device *netdev = NULL; > + > + netdev = dev_get_by_index(sock_net(sk), inet->cork.fl.flowi_oif); No need for an assignment in the variable declaration here. You immediately set it to something

Re: [Crypto v4 03/12] support for inline tls

From: Atul Gupta Date: Mon, 12 Feb 2018 17:34:28 +0530 > +static int get_tls_prot(struct sock *sk) > +{ > + struct tls_context *ctx = tls_get_ctx(sk); > + struct net_device *netdev; > + struct tls_device *dev; > + > + /* Device bound to specific IP */ > +

Re: [Crypto v4 01/12] tls: tls_device struct to register TLS drivers

From: Atul Gupta Date: Mon, 12 Feb 2018 17:33:48 +0530 > + /* When calling get_netdev, the HW vendor's driver should return the > + * net device of device @device at port @port_num or NULL if such > + * a net device doesn't exist > + */ > + struct

Re: [PATCHv2] tls: Add support for encryption using async offload accelerator

From: Vakul Garg Date: Wed, 31 Jan 2018 21:34:37 +0530 > Async crypto accelerators (e.g. drivers/crypto/caam) support offloading > GCM operation. If they are enabled, crypto_aead_encrypt() return error > code -EINPROGRESS. In this case tls_do_encryption() needs to wait on a >

Re: [PATCH] sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64

From: Corentin Labbe Date: Tue, 23 Jan 2018 14:33:14 + > This patch fixes the typo CONFIG_CRYPTO_DES_SPARC64 => > CONFIG_CRYPTO_CAMELLIA_SPARC64 > > Fixes: 81658ad0d923 ("sparc64: Add CAMELLIA driver making use of the new > camellia opcodes.") > Signed-off-by:

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

From: "Yang Shi" Date: Fri, 05 Jan 2018 06:46:48 +0800 > Any more comment on this change? These patches were not really submitted properly. If you post a series, the series goes to one destination and one tree. If they are supposed to go to multiple trees, submit them

Re: [PATCH] crypto: n2 - cure use after free

From: Jan Engelhardt Date: Tue, 19 Dec 2017 19:09:07 +0100 > queue_cache_init is first called for the Control Word Queue > (n2_crypto_probe). At that time, queue_cache[0] is NULL and a new > kmem_cache will be allocated. If the subsequent n2_register_algs call > fails, the

Re: [PATCH] crypto: n2 - cure use after free

From: Jan Engelhardt Date: Tue, 19 Dec 2017 16:42:39 +0100 (CET) > Nevertheless, I think that the error pathing in n2_core.c should be made > robust as well. I completely agree. > Should I resubmit with a new commit message? Yes.

Re: [PATCH v2 2/2] chcr: Add support for Inline IPSec

From: Atul Gupta Date: Thu, 9 Nov 2017 16:59:01 +0530 > register xfrmdev_ops callbacks, Send IPsec tunneled data > to HW for inline processing. > The driver use hardware crypto accelerator to encrypt and > generate ICV for the transmitted packet in Inline mode. > >

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

From: Herbert Xu Date: Thu, 5 Oct 2017 11:40:54 +0800 > On Tue, Oct 03, 2017 at 07:45:06PM -0300, Marcelo Ricardo Leitner wrote: >> >> > Usually if you're invoking setkey from a non-sleeping code-path >> > you're probably doing something wrong. >> >> Usually but not

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

From: Allen Pais Date: Wed, 13 Sep 2017 13:02:15 +0530 > Signed-off-by: Allen Pais This is quite pointless as the caller doesn't do anything with the value, it just tests whether a negative value is returned or not.

Re: [PATCH 1/2] crypto: n2 - remove null check before kfree

From: Himanshu Jha Date: Sun, 27 Aug 2017 02:45:29 +0530 > kfree on NULL pointer is a no-op and therefore checking it is redundant. > > Signed-off-by: Himanshu Jha Acked-by: David S. Miller

Re: [PATCH] crypto: n2_core: Convert to using %pOF instead of full_name

From: Rob Herring Date: Tue, 18 Jul 2017 16:42:56 -0500 > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring

Re: [GIT] Networking

From: Herbert Xu Date: Mon, 10 Jul 2017 22:00:48 +0800 > crypto: af_alg - Avoid sock_graft call warning > > The newly added sock_graft warning triggers in af_alg_accept. > It's harmless as we're essentially doing sock->sk = sock->sk. > > The sock_graft call is

Re: [PATCH] crypto: cavium: make several functions static

From: Colin King Date: Tue, 20 Jun 2017 11:35:50 +0100 > From: Colin Ian King > > The functions cvm_encrypt, cvm_decrypt, cvm_xts_setkey and > cvm_enc_dec_init does not need to be in global scope, so make > them static. > > Signed-off-by:

Re: Crypto Fixes for 4.12

From: Theodore Ts'o <ty...@mit.edu> Date: Fri, 16 Jun 2017 08:50:07 -0400 > On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote: >> As a side note, ext4 does something similar with a private >> implementation, but it doesn't use something the evaluates to an >&g

Re: [PATCH v3 net-next 0/4] kernel TLS

From: Dave Watson Date: Wed, 14 Jun 2017 11:36:54 -0700 > This series adds support for kernel TLS encryption over TCP sockets. > A standard TCP socket is converted to a TLS socket using a setsockopt. > Only symmetric crypto is done in the kernel, as well as TLS record >

Re: [PATCH] crypto: n2: make of_device_ids const

From: Arvind Yadav Date: Thu, 15 Jun 2017 17:28:10 +0530 > of_device_ids are not supposed to change at runtime. All functions > working with of_device_ids provided by work with const > of_device_ids. So mark the non-const structs as const. > > File size before: >

Re: Crypto Fixes for 4.12

From: Linus Torvalds Date: Thu, 15 Jun 2017 18:04:44 +0900 > There's a fair number of SHASH_DESC_ON_STACK users, are all the others > safe for some random reason that just happens to be about code > generation? Did people actually verify that? I looked at the code

Re: Crypto Fixes for 4.12

From: Herbert Xu Date: Thu, 15 Jun 2017 17:42:10 +0800 > On Thu, Jun 15, 2017 at 06:04:44PM +0900, Linus Torvalds wrote: >> There's a fair number of SHASH_DESC_ON_STACK users, are all the others >> safe for some random reason that just happens to be about code >>

Re: [PATCH v3 net-next 0/4] kernel TLS

From: Dave Watson Date: Wed, 14 Jun 2017 11:36:54 -0700 > This series adds support for kernel TLS encryption over TCP sockets. > A standard TCP socket is converted to a TLS socket using a setsockopt. > Only symmetric crypto is done in the kernel, as well as TLS record >

Re: Crypto Fixes for 4.12

From: Herbert Xu Date: Thu, 8 Jun 2017 17:23:21 +0800 > This push fixes a couple of places in the crypto code that were > doing interruptible sleeps dangerously. They have been converted > to use non-interruptible sleeps. This push also fixes a bug in >

Re: [PATCH v2 net-next 1/4] tcp: ULP infrastructure

From: Dave Watson Date: Tue, 6 Jun 2017 10:00:20 -0700 > +EXPORT_SYMBOL(tcp_register_ulp); EXPORT_SYMBOL_GPL() please. > +EXPORT_SYMBOL(tcp_unregister_ulp); Likewise.

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

From: David Miller <da...@davemloft.net> Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT) > > On sparc, if we have an alloca() like situation, as is the case with > SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack > memory. The result can be that the value is c

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

From: David Miller <da...@davemloft.net> Date: Fri, 02 Jun 2017 14:39:06 -0400 (EDT) > From: "Darrick J. Wong" <darrick.w...@oracle.com> > Date: Fri, 2 Jun 2017 11:08:08 -0700 > >> ext4/jbd2's crc32c implementations will also need a fix like this for &

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

From: "Darrick J. Wong" Date: Fri, 2 Jun 2017 11:08:08 -0700 > ext4/jbd2's crc32c implementations will also need a fix like this for > {ext4,jbd2}_chksum. Note that both of these modules call the crypto api > directly to avoid a static dependence on libcrc32c; this was

crypto: Work around deallocated stack frame reference gcc bug on sparc.

On sparc, if we have an alloca() like situation, as is the case with SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack memory. The result can be that the value is clobbered if a trap or interrupt arrives at just the right instruction. It only occurs if the function ends

Re: [sparc64] crc32c misbehave

From: David Miller <da...@davemloft.net> Date: Wed, 31 May 2017 11:53:35 -0400 (EDT) > Can you try something like disabling cpu IRQs around the crc32c() function > in lib/libcrc32c.c? Something like: > > u32 retval; > > local_irq_disable(); >

Re: [sparc64] crc32c misbehave

From: Anatoly Pugachev Date: Wed, 31 May 2017 14:56:52 +0300 > While debugging occasional crc32c checksum errors with xfs disk reads on > sparc64 (T5 [sun4v] 3.6 GHz CPU ldom, debian unstable/sid), Eric have found > that crc32c sometimes returns wrong checksum for data. Eric

Re: [PATCH net-next 3/4] tls: kernel TLS support

From: Eric Dumazet Date: Fri, 26 May 2017 07:16:59 -0700 > On Wed, 2017-05-24 at 09:27 -0700, Dave Watson wrote: >> Software implementation of transport layer security, implemented using ULP >> infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg

Re: [PATCH net-next 0/4] kernel TLS

From: Dave Watson Date: Wed, 24 May 2017 09:26:33 -0700 > This series adds support for kernel TLS encryption over TCP sockets. > A standard TCP socket is converted to a TLS socket using a setsockopt. > Only symmetric crypto is done in the kernel, as well as TLS record >

Re: [PATCH net-next 2/4] tcp: export do_tcp_sendpages and tcp_rate_check_app_limited functions

From: Dave Watson Date: Wed, 24 May 2017 09:26:57 -0700 > Export do_tcp_sendpages and tcp_rate_check_app_limited, since tls will need to > sendpages while the socket is already locked. > > tcp_sendpage is exported, but requires the socket lock to not be held already. > >

Re: [PATCH] crypto: hifn_795x: Fix a handful of minor bugs spotted by eye

From: Logan Gunthorpe Date: Wed, 17 May 2017 21:33:22 -0600 > > > On 17/05/17 09:26 PM, Herbert Xu wrote: >> On Thu, May 18, 2017 at 11:25:06AM +0800, Herbert Xu wrote: >>> On Fri, Apr 28, 2017 at 11:02:40AM -0600, Logan Gunthorpe wrote: * Cleaned up the formatting of

Re: [PATCH 2/2] n2rng: Combine substrings for two messages in n2rng_probe()

From: Herbert Xu Date: Fri, 21 Apr 2017 19:36:41 +0800 > On Wed, Apr 19, 2017 at 11:11:35AM +0200, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Wed, 19 Apr 2017 10:50:04 +0200 >> >> The script "checkpatch.pl" pointed

Re: [patch V2 13/13] crypto: n2 - Replace racy task affinity logic

From: Thomas Gleixner Date: Thu, 13 Apr 2017 10:20:23 +0200 (CEST) > spu_queue_register() needs to invoke setup functions on a particular > CPU. This is achieved by temporarily setting the affinity of the > calling user space thread to the requested CPU and reset it to the

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

From: Herbert Xu Date: Thu, 6 Apr 2017 16:15:09 +0800 > As the final patch depends on all three it would be easiest if > we pushed the xfrm patch through the crypto tree. Steffen/David? No objections from me for this going through the crypto tree.

Re: [RFC TLS Offload Support 00/15] cover letter

From: Aviad Yehezkel Date: Tue, 28 Mar 2017 16:26:17 +0300 > TLS Tx crypto offload is a new feature of network devices. It > enables the kernel TLS socket to skip encryption and authentication > operations on the transmit side of the data path, delegating those > to the

Re: [PATCH] padata: avoid race in reordering

From: Steffen Klassert Date: Fri, 24 Mar 2017 10:41:59 +0100 > On Thu, Mar 23, 2017 at 12:24:43PM +0100, Jason A. Donenfeld wrote: >> Under extremely heavy uses of padata, crashes occur, and with list >> debugging turned on, this happens instead: ... >>

Re: [PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure

From: Eric Biggers Date: Thu, 23 Mar 2017 13:39:46 -0700 > From: Eric Biggers > > In the generic XTS and LRW algorithms, for input data > 128 bytes, a > temporary buffer is allocated to hold the values to be XOR'ed with the > data before and after

Re: [PATCH] crypto: ixp4xx - Use sg_virt()

From: Geliang Tang Date: Thu, 23 Mar 2017 21:16:30 +0800 > Use sg_virt() instead of open-coding it. > > Signed-off-by: Geliang Tang Acked-by: David S. Miller

Re: [PATCH v7 0/5] Update LZ4 compressor module

r something like that? Since in linux-kernel the patch >> seems to get delivered. >> I could otherwise CC you if you wish. >> > > If I'm not mistaken, David Miller is the admin of the mail server on > vger.kernel.org, and he already happens to be Cc'ed on this thread, so ma

Re: [sparc64] cryptomgr_test OOPS kernel 4.9.0+

From: Anatoly Pugachev Date: Sun, 25 Dec 2016 20:56:08 +0300 > Disabling kernel config option > CRYPTO_MANAGER_DISABLE_TESTS > i.e. enable run-time self tests, makes kernel unbootable: > > tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9 I think

Re: [sparc64] cryptomgr_test OOPS kernel 4.9.0+

From: Anatoly Pugachev Date: Sun, 25 Dec 2016 20:56:08 +0300 > Disabling kernel config option > CRYPTO_MANAGER_DISABLE_TESTS > i.e. enable run-time self tests, makes kernel unbootable: > > tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9 I'm

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

From: "Jason A. Donenfeld" Date: Wed, 14 Dec 2016 13:53:10 +0100 > In all current uses of __packed in the code, I think the impact is > precisely zero, because all structures have members in descending > order of size, with each member being a perfect multiple of the one > below

Re: [PATCH net-next] cxgb4: Allocate Tx queues dynamically

From: Atul Gupta Date: Fri, 18 Nov 2016 16:37:40 +0530 > From: Hariprasad Shenai > > Allocate resources dynamically for Upper layer driver's (ULD) like > cxgbit, iw_cxgb4, cxgb4i and chcr. The resources allocated include Tx > queues which are

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

From: "Jason A. Donenfeld" Date: Thu, 3 Nov 2016 08:24:57 +0100 > Hi Herbert, > > On Thu, Nov 3, 2016 at 1:49 AM, Herbert Xu > wrote: >> FWIW I'd rather live with a 6% slowdown than having two different >> code paths in the generic code. Anyone

Re: [PATCH net-next] chcr/cxgb4i/cxgbit/RDMA/cxgb4: Allocate resources dynamically for all cxgb4 ULD's

From: Hariprasad Shenai Date: Sat, 17 Sep 2016 08:12:39 +0530 > Allocate resources dynamically to cxgb4's Upper layer driver's(ULD) like > cxgbit, iw_cxgb4 and cxgb4i. Allocate resources when they register with > cxgb4 driver and free them while unregistering. All the

Re: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

From: Herbert Xu <herb...@gondor.apana.org.au> Date: Fri, 19 Aug 2016 14:15:43 +0800 > On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote: >> From: Hariprasad Shenai <haripra...@chelsio.com> >> Date: Wed, 17 Aug 2016 12:33:02 +0530 >> >> >

Re: [PATCHv3 net-next 0/4] crypto/chcr: Add support for Chelsio Crypto Driver

From: Hariprasad Shenai Date: Wed, 17 Aug 2016 12:33:02 +0530 > This patch series adds support for Chelsio Crypto driver. Herbert, what do you want to do with this? I can push it via net-next if you like. -- To unsubscribe from this list: send the line "unsubscribe

Re: AF_ALG broken?

From: Russell King - ARM Linux Date: Mon, 8 Aug 2016 23:58:51 +0100 > I don't know, but this seems to go completely against Linus' no > userspace regressions, which seems to be an absolute requirement of > all kernel development... Linus flames people for arguing against >

Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware

From: Yeshaswi M R Gowda Date: Mon, 18 Jul 2016 22:42:14 -0700 > +config CRYPTO_DEV_CHELSIO > + tristate "Chelsio Crypto Co-processor Driver" > + depends on PCI && NETDEVICES && ETHERNET > + select CRYPTO_SHA1 > + select CRYPTO_SHA256 > + select

Re: [sparc] niagara2 cpu, opcodes not available message?

From: Anatoly Pugachev Date: Wed, 8 Jun 2016 20:30:40 +0300 > Can someone please tell, why do we get a bunch of the following > messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220, > T5140, and T5240 servers) > > Asking, because I see the following lines on

Re: [crypto / sparc64] cryptomgr_test OOPS

From: Herbert Xu Date: Thu, 5 May 2016 16:42:49 +0800 > Subject: crypto: testmgr - Use kmalloc memory for RSA input > > As akcipher uses an SG interface, you must not use vmalloc memory > as input for it. This patch fixes testmgr to copy the vmalloc > test vectors

Re: [crypto / sparc64] cryptomgr_test OOPS

From: Anatoly Pugachev Date: Wed, 4 May 2016 22:10:47 +0300 > Here's a quick diff related to crypto for debian kernel configs: > > $ diff -u /boot/config-4.5.0-2-sparc64-smp /boot/config-4.6.0-rc5-sparc64-smp > @@ -5299,10 +5380,9 @@ > CONFIG_CRYPTO_RNG=m >

Re: [crypto / sparc64] cryptomgr_test OOPS

From: Anatoly Pugachev Date: Tue, 3 May 2016 16:54:18 +0300 > I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not > happen, if I set the following kernel option: > > CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y > > Can someone please look at

Re: [PATCH 2/2] n2rng: Attach on T5/M5, T7/M7 SPARC CPUs

From: Anatoly Pugachev Date: Mon, 25 Jan 2016 19:09:39 +0300 > n2rng: Attach on T5/M5, T7/M7 SPARC CPUs > > Signed-off-by: Anatoly Pugachev Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 1/2] n2rng: documentation, add DT bindings, vendor prefixes

From: Anatoly Pugachev Date: Mon, 25 Jan 2016 19:09:21 +0300 > n2rng: documentation, add DT bindings, vendor prefixes > > Signed-off-by: Anatoly Pugachev Acked-by: David S. Miller -- To unsubscribe from this list: send the line

Re: [PATCH 19/26] ipsec: Use skcipher and ahash when probing algorithms

From: Herbert Xu Date: Sun, 24 Jan 2016 21:19:11 +0800 > This patch removes the last reference to hash and ablkcipher from > IPsec and replaces them with ahash and skcipher respectively. For > skcipher there is currently no difference at all, while for ahash > the

Re: [PATCH 25/26] sctp: Use shash

From: Herbert Xu Date: Sun, 24 Jan 2016 21:20:12 +0800 > This patch replaces uses of the long obsolete hash interface with > shash. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- To unsubscribe from

Re: [PATCH 26/26] tcp: Use ahash

From: Herbert Xu Date: Sun, 24 Jan 2016 21:20:23 +0800 > This patch replaces uses of the long obsolete hash interface with > ahash. > > Signed-off-by: Herbert Xu Acked-by: David S. Miller -- To unsubscribe from

Re: [PATCH] net: fix uninitialized variable issue

From: Tadeusz Struk Date: Tue, 15 Dec 2015 10:46:17 -0800 > msg_iocb needs to be initialized on the recv/recvfrom path. > Otherwise afalg will wrongly interpret it as an async call. > > Cc: sta...@vger.kernel.org > Reported-by: Harald Freudenberger

Re: [PATCH v2 0/3] dmaengine: Add supports for APM X-Gene SoC CRC32C accerlerator driver

From: Herbert Xu Date: Wed, 9 Dec 2015 16:44:58 +0800 > On Wed, Dec 09, 2015 at 02:13:32PM +0530, Rameshwar Sahu wrote: >> >> Yes, we are not upstream in-kernel users right now, but later client >> ma upstream there patches. > > Well I'd prefer to not take any

Re: ipsec impact on performance

From: Sowmini Varadhan Date: Tue, 1 Dec 2015 12:59:53 -0500 > I instrumented iperf with and without ipsec, just using esp-null, > and 1 thread, to keep things simple. I'm seeing some pretty dismal > performance numbers with ipsec, and trying to think of ways to >

Re: [PATCH] crypto: n2 - Use platform_register/unregister_drivers()

From: Thierry Reding Date: Wed, 2 Dec 2015 17:16:36 +0100 > From: Thierry Reding > > These new helpers simplify implementing multi-driver modules and > properly handle failure to register one driver by unregistering all > previously registered

Re: [PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

From: Steffen Klassert Date: Wed, 21 Oct 2015 08:57:04 +0200 > On Mon, Oct 19, 2015 at 05:23:29PM -0400, Sowmini Varadhan wrote: >> On sparc, deleting established SAs (e.g., by restarting ipsec >> at the peer) results in unaligned access messages via >> xfrm_del_sa

Re: [PATCH net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA

From: Sowmini Varadhan Date: Wed, 21 Oct 2015 06:54:42 -0400 > On (10/21/15 08:57), Steffen Klassert wrote: >> > --- a/net/xfrm/xfrm_user.c >> > +++ b/net/xfrm/xfrm_user.c >> > @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, >> > const struct

Re: unaligned access in pkcs7_verify

From: Herbert Xu Date: Mon, 12 Oct 2015 21:32:09 +0800 > The sparc sha algorithms themselves need to declare the alignment > that they require. Currently they claim to be able to handle any > alignment which appears to not be the case. The sparc SHA assembler can

Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256

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? Temporary workaround if a bug is found. There is really no reason to

Re: [PATCH 0/4] crypto: [sha] x86 SHA extension optimization of SHA1 and SHA256

From: Tim Chen Date: Thu, 10 Sep 2015 15:26:52 -0700 > > The new x86 SHA extensions provide new hardware accelerated instructions > for computing SHA1 and SHA256 hashes. This patch series provide the > assembly routines for SHA1 and SHA256 computation using these new

Re: [PATCH 0/7] crypto: Convert all AEAD users to new interface

From: Herbert Xu herb...@gondor.apana.org.au Date: Thu, 21 May 2015 18:39:39 +0800 This series of patches convert all in-tree AEAD users that I could find to the new single SG list interface. For IPsec it also adopts the new explicit IV generator scheme. No objections on my end. I assume

Re: [PATCH 0/6] crypto: Make all AEAD users include aead.h

From: Herbert Xu herb...@gondor.apana.org.au Date: Wed, 22 Apr 2015 15:04:55 +0800 This series adds inclusions of aead.h to all AEAD users including AEAD implementors (where it's internal/aead.h). This is necessary because I'll be adding an updated AEAD interface and that will live in aead.h

Re: CCM/GCM implementation defect

From: Herbert Xu herb...@gondor.apana.org.au Date: Thu, 23 Apr 2015 11:26:20 +0800 In order to fix this without breaking backwards compatibility, my plan is to introduce new templates such as rfc4106v2 which implement the RFC correctly. The existing templates will be retained so that current

[PATCH] crypto: Fix aead_{sendmsg,recvmsg}() signatures.

The kiocb argument is no longer present. Signed-off-by: David S. Miller da...@davemloft.net diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c index 527d27b..95ad689 100644 --- a/crypto/algif_aead.c +++ b/crypto/algif_aead.c @@ -163,8 +163,7 @@ static void aead_data_wakeup(struct sock *sk)

Re: [PATCH] crypto: Fix aead_{sendmsg,recvmsg}() signatures.

From: Herbert Xu herb...@gondor.apana.org.au Date: Sat, 18 Apr 2015 09:33:17 +0800 On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote: The kiocb argument is no longer present. Signed-off-by: David S. Miller da...@davemloft.net I think Linus has already fixed

Re: [PATCH v2 net-next] crypto: algif - explicitly mark end of data

From: Tadeusz Struk tadeusz.st...@intel.com Date: Wed, 01 Apr 2015 13:53:06 -0700 After the TX sgl is expanded we need to explicitly mark end of data at the last buffer that contains data. Changes in v2 - use type 'bool' and true/false for 'mark'. Signed-off-by: Tadeusz Struk

Re: [PATCH net-next] crypto: af_alg - make exports consistant

From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:43 -0700 Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to

Re: [PATCH net-next] crypto: algif - use kmalloc instead of kzalloc

From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:44 -0700 No need to use kzalloc to allocate sgls as the structure is initialized anyway. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com Applied. -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH net-next] crypto: algif - explicitly mark end of data

From: Tadeusz Struk tadeusz.st...@intel.com Date: Mon, 30 Mar 2015 14:25:43 -0700 + int mark = 0, err = -ENOMEM; lock_sock(sk); req = kmalloc(reqlen, GFP_KERNEL); ... @@ -573,10 +572,11 @@ static int skcipher_recvmsg_async(struct socket *sock, struct msghdr *msg,

Re: [PATCH net-next] crypto: algif - fix warn: unsigned 'used' is never less than zero

From: Tadeusz Struk tadeusz.st...@intel.com Date: Wed, 25 Mar 2015 07:29:19 -0700 Change type from unsigned long to int to fix an issue reported by kbuild robot: crypto/algif_skcipher.c:596 skcipher_recvmsg_async() warn: unsigned 'used' is never less than zero. Signed-off-by: Tadeusz

Re: [PATCH v3 net-next 0/3] Add support for async socket operations

From: Tadeusz Struk tadeusz.st...@intel.com Date: Thu, 19 Mar 2015 12:31:19 -0700 After the iocb parameter has been removed from sendmsg() and recvmsg() ops the socket layer, and the network stack no longer support async operations. This patch set adds support for asynchronous operations on

Re: [PATCH v2 net-next 0/4] Add support for async socket operations

From: Tadeusz Struk tadeusz.st...@intel.com Date: Wed, 18 Mar 2015 13:59:30 -0700 What's your take on this patch set? I'm really busy so waiting for Al to give some feedback first. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to

Re: [PATCH 2/4] net: esp: check CRYPTO_TFM_REQ_DMA flag when allocating crypto request

From: Horia Geantă horia.gea...@freescale.com Date: Sat, 14 Mar 2015 14:16:37 +0200 However, ESP is not using aead_request_alloc(). Then find a way to adjust it to do so. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to

Re: [PATCH 2/4] net: esp: check CRYPTO_TFM_REQ_DMA flag when allocating crypto request

From: Horia Geanta horia.gea...@freescale.com Date: Fri, 13 Mar 2015 19:15:22 +0200 Some crypto backends might require the requests' private contexts to be allocated in DMA-able memory. Signed-off-by: Horia Geanta horia.gea...@freescale.com No way. Upper layers should be absolutely not

Re: [PATCH] mm: kill kmemcheck

From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 09:39:33 -0400 On 03/11/2015 08:40 AM, Steven Rostedt wrote: On Wed, 11 Mar 2015 08:34:46 -0400 Sasha Levin sasha.le...@oracle.com wrote: Fair enough. We knew there are existing kmemcheck users, but KASan should be

Re: [PATCH] mm: kill kmemcheck

From: Andrey Ryabinin ryabinin@gmail.com Date: Wed, 11 Mar 2015 23:01:00 +0300 2015-03-11 21:44 GMT+03:00 David Miller da...@davemloft.net: From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 13:25:47 -0400 You're probably wondering why there are changes to SPARC

Re: [PATCH] mm: kill kmemcheck

From: Sasha Levin sasha.le...@oracle.com Date: Wed, 11 Mar 2015 13:25:47 -0400 You're probably wondering why there are changes to SPARC in that patchset? :) Libsanitizer doesn't even build have the time on sparc, the release manager has to hand patch it into building again every major release

Re: net: Remove iocb argument from sendmsg and recvmsg

From: Tadeusz Struk tadeusz.st...@intel.com Date: Tue, 10 Mar 2015 20:25:29 -0700 In my opinion this is not about a single, special case, but rather about being able to support asynchronous operations on socket interface. Nobody used the socket AIO facility for two decades, it just rotted and

Re: net: Remove iocb argument from sendmsg and recvmsg

From: Ying Xue ying@windriver.com Date: Wed, 11 Mar 2015 11:18:01 +0800 Sorry, I did not realize the case when I created the commit. However, although I don't understand its scenario, in my opinion, adding one redundant argument for all sockets to satisfy the special case seems

Re: net: Remove iocb argument from sendmsg and recvmsg

Because of the way you quoted the patch, it looked like a list posting looping back to the list again, because of the List-ID: email header. Therefore your posting was blocked and you'll have to resend your posting in a way such that this doesn't happen. -- To unsubscribe from this list: send

Re: [PATCH 4/6] crypto: sparc64/des - add des3_ede module alias

From: Mathias Krause mini...@googlemail.com Date: Sun, 11 Jan 2015 18:17:45 +0100 This module provides implementations for des3_ede, too. Announce those via an appropriate crypto module alias so it can be used in favour to the generic C implementation. Cc: David S. Miller

Re: [PATCH 2/6] crypto: sparc64/aes - fix module description

From: Mathias Krause mini...@googlemail.com Date: Sun, 11 Jan 2015 18:17:43 +0100 AES is a block cipher, not a hash. Cc: David S. Miller da...@davemloft.net Signed-off-by: Mathias Krause mini...@googlemail.com Acked-by: David S. Miller da...@davemloft.net -- To unsubscribe from this list:

Re: [PATCH 3/6] crypto: sparc64/camellia - fix module alias

From: Mathias Krause mini...@googlemail.com Date: Sun, 11 Jan 2015 18:17:44 +0100 The module alias should be camellia, not aes. Cc: David S. Miller da...@davemloft.net Signed-off-by: Mathias Krause mini...@googlemail.com Acked-by: David S. Miller da...@davemloft.net -- To unsubscribe from

Re: [PATCH 5/6] crypto: sparc64/md5 - fix module description

From: Mathias Krause mini...@googlemail.com Date: Sun, 11 Jan 2015 18:17:46 +0100 MD5 is not SHA1. Cc: David S. Miller da...@davemloft.net Signed-off-by: Mathias Krause mini...@googlemail.com Acked-by: David S. Miller da...@davemloft.net -- To unsubscribe from this list: send the line

Re: [PATCH] crypto: Remove unnecessary KERN_INFO from testmgr.c

From: Masanari Iida standby2...@gmail.com Date: Tue, 7 Oct 2014 00:37:54 +0900 This patch remove unncessary KERN_INFO from pr_info within testmgr.c Signed-off-by: Masanari Iida standby2...@gmail.com Acked-by: David S. Miller da...@davemloft.net -- To unsubscribe from this list: send the

  1   2   3   >