On Mon, Dec 07, 2020 at 02:03:03PM +0100, Phil Sutter wrote:
> With an IPsec tunnel without dedicated interface, netfilter sees locally
> generated packets twice as they exit the physical interface: Once as "the
> inner packet" with IPsec context attached and once as the encrypted
> (ESP) packet.
>
On Fri, Nov 27, 2020 at 03:10:48PM +0100, Phil Sutter wrote:
> On Fri, Nov 27, 2020 at 10:55:11AM +0100, Steffen Klassert wrote:
> > On Thu, Nov 26, 2020 at 02:12:00PM +0100, Phil Sutter wrote:
> > > > >
> > > > > Is this a bug or an expected quirk when usin
On Thu, Nov 26, 2020 at 02:12:00PM +0100, Phil Sutter wrote:
> > >
> > > Is this a bug or an expected quirk when using XFRM interface?
> >
> > This is expected behaviour. The xfrm interfaces are plaintext devices,
> > the plaintext packets are routed to the xfrm interface which guarantees
> > tra
Hi Phil,
On Wed, Nov 25, 2020 at 12:23:42PM +0100, Phil Sutter wrote:
> Hi Steffen,
>
> I am working on a ticket complaining about netfilter policy match
> missing packets in OUTPUT chain if XFRM interface is being used.
>
> I don't fully overlook the relevant code path, but it seems like
> skb_
Daniel Jordan
Great, thanks a lot Daniel!
Acked-by: Steffen Klassert
On Wed, Aug 26, 2020 at 10:59:23AM -0400, Daniel Jordan wrote:
> I volunteer to review padata changes for the foreseeable future.
>
> Signed-off-by: Daniel Jordan
> Cc: Herbert Xu
> Cc: Steffen Klassert
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
On Wed, Jun 10, 2020 at 09:14:34AM -0700, Eric Biggers wrote:
> This series consolidates and modernizes the lists of crypto algorithms
> that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
> since it no longer gets selected automatically by other things.
>
> See previous discussi
On Mon, Jun 15, 2020 at 03:13:15PM -0700, Eric Biggers wrote:
> This series consolidates and modernizes the lists of crypto algorithms
> that are selected by the IPsec kconfig options, and adds CRYPTO_SEQIV
> since it no longer gets selected automatically by other things.
>
> See previous discussi
On Fri, Jun 05, 2020 at 11:00:23AM -0700, Eric Biggers wrote:
> On Fri, Jun 05, 2020 at 10:39:31AM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> > index 23ba5045e3d3..6520b30883cf 100644
> > --- a/net/ipv4/Kconfig
> > +++ b/net/ipv4/K
: Eric Biggers
[SK: also require that the underlying algorithm doesn't need a fallback]
Signed-off-by: Steffen Klassert
---
crypto/pcrypt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/crypto/pcrypt.c b/crypto/pcrypt.c
index 543792e0ebf0..932a77b61b47 100644
--- a/
On Wed, Sep 18, 2019 at 10:15:45PM -0700, Eric Biggers wrote:
>
> Reproducer involves pcrypt, so probably the pcrypt deadlock again...
> https://lkml.kernel.org/linux-crypto/20190817054743.GE8209@sol.localdomain/
I'll submit the patch I proposed here in case noone has a better idea
how to fix thi
lgfd, (void *)&addr, sizeof(addr));
setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, 20);
reqfd = accept(algfd, 0, 0);
write(reqfd, buf, 32);
read(reqfd, buf, 16);
}
Reported-by:
syzbot+56c7151cad94eec37c521f0e47d2eee53f936..
queues.
Looks good!
I did a test with IPsec pcrypt and it seems to work as expected.
Crypto load gets distributed, no network packet reordering.
Acked-by: Steffen Klassert
On Wed, Jul 17, 2019 at 04:47:40PM +0800, Herbert Xu wrote:
> On Wed, Jul 17, 2019 at 10:28:15AM +0200, Steffen Klassert wrote:
> >
> > I had a patch to support crypto backlog some years ago,
> > but testing with dm-crypt did not show any performance
> > improvement. So
On Tue, Jul 16, 2019 at 09:23:45PM +0800, Herbert Xu wrote:
> On Tue, Jul 16, 2019 at 09:09:28PM +0800, Herbert Xu wrote:
> >
> > Hmm, it doesn't work because the refcnt is attached to the old
> > pd. That shouldn't be a problem though as we could simply ignore
> > the refcnt in padata_flush_queue
On Tue, Jul 16, 2019 at 09:09:28PM +0800, Herbert Xu wrote:
>
> However, I think this leads to another bug in that pcrypt doesn't
> support dm-crypt properly. It never does the backlog stuff and
> therefore can't guarantee reliable processing which dm-crypt requires.
>
> Is it intentional to onl
On Tue, Jul 16, 2019 at 06:04:47PM +0800, Herbert Xu wrote:
> On Mon, Jul 15, 2019 at 12:10:46PM -0400, Daniel Jordan wrote:
> >
> > I've been wrong before plenty of times, and there's nothing preventing this
> > from being one of those times :) , but in this case I believe what I'm
> > showing
>
On Fri, Jul 12, 2019 at 06:06:36PM +0800, Herbert Xu wrote:
> Daniel Jordan wrote:
> >
> > CPU0 CPU1
> >
> > padata_reorder padata_do_serial
> > LOAD reorder_objects // 0
> > INC reorder_objects // 1
>
Hi Daniel,
On Tue, May 28, 2019 at 07:37:07PM -0400, Daniel Jordan wrote:
> Hi Steffen,
>
> I'm working on some padata patches and stumbled across this thread about the
> purpose of the callback CPU in padata_do_parallel.
>
> https://lore.kernel.org/lkml/20100402112326.ga19...@secunet.com/
On Wed, Feb 20, 2019 at 12:06:28PM +0800, Herbert Xu wrote:
> On Wed, Apr 18, 2018 at 07:35:33AM +0200, Steffen Klassert wrote:
> >
> > Yes sure, I just wanted to know if it is worth to think about
> > preventing template recursions. If there is a valid usecase,
> >
On Thu, Jan 03, 2019 at 04:16:56PM +0530, Harsh Jain wrote:
>
> On 02-01-2019 18:21, Herbert Xu wrote:
> > Does this occur if you use software crypto on the receiving end
> > while keeping the sending end unchanged?
>
> I tried with "authencesn(hmac(sha1-ssse3),cbc(aes-asm))" on both sides.
>
>
On Thu, Sep 27, 2018 at 10:35:48AM +0200, Ard Biesheuvel wrote:
> (+ Stefan)
>
> On Wed, 26 Sep 2018 at 22:24, syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:739d0def85ca Merge branch 'hv_netvsc-Support-LRO-RSC-in-th..
> > git tree: net-n
On Mon, Apr 09, 2018 at 12:07:39PM -0700, Eric Biggers wrote:
> On Mon, Apr 09, 2018 at 10:58:08AM +0200, Steffen Klassert wrote:
> > On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote:
> > >
> > > Steffen, how feasible do you think would it be to make each
On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote:
> On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote:
> > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > If the pcrypt template is used multiple times in an algorithm, then a
st,
> struct crypto_alg *alg)
> {
> + /* Recursive pcrypt deadlocks due to the shared padata_instance */
> + if (!strncmp(alg->cra_driver_name, "pcrypt(", 7) ||
> + strstr(alg->cra_driver_name, "(pcrypt(") ||
> + strstr(alg->cra_driver_name, ",pcrypt("))
> + return -EINVAL;
> +
This looks ok to me.
Acked-by: Steffen Klassert
On Wed, Jan 31, 2018 at 10:54:57AM -0800, Junaid Shahid wrote:
> On Wed, Jan 31, 2018 at 12:13 AM, Steffen Klassert
> wrote:
> >
> > I wonder which special usecase you have in mind that will be improved
> > by your patches.
> >
>
> This is not related to IPsec
rypto_user_stat.c
> > => this imply also to change makefile (rename crypto_user.c to
> > crypto_user_base.c) since crypto_user.ko is made of two files.
> >
> > Which one do you prefer ?
>
> I think you should check with the crconf author, Steffen Klassert
&
Hi Junaid.
On Tue, Jan 23, 2018 at 12:19:12PM -0800, Junaid Shahid wrote:
> Changes in v2:
> - Integrated https://patchwork.kernel.org/patch/10173981
>
> Currently, the AESNI gcm(aes) implementation uses zero-copy only when the
> entire src and dest request buffers, including the AAD, the data an
On Sat, Dec 23, 2017 at 02:29:42PM -0600, Eric Biggers wrote:
> [+Cc Steffen Klassert ]
>
>
> I was able to reproduce this by trying to use 'pcrypt' recursively. I am not
> 100% sure it is the exact same bug, but it probably is. Here is a C
> reproducer:
>
>
nse-Identifier: GPL-2.0
> > /*
> > * padata.c - generic interface to process data streams in parallel
> > *
>
> Steffen, are you OK with this patch?
Yes, I'm ok with this.
Acked-by: Steffen Klassert
a: set cpu_index of unused CPUs to -1
> padata: ensure the reorder timer callback runs on the correct CPU
> padata: ensure padata_do_serial() runs on the correct CPU
Looks good, thanks!
Acked-by: Steffen Klassert
On Thu, Jul 13, 2017 at 04:51:10PM +0200, Stephan Müller wrote:
> Am Donnerstag, 13. Juli 2017, 16:22:32 CEST schrieb Christian Langrock:
>
> Hi Christian,
>
> > With this patch it's possible to use crypto user API form all
> > network namespaces, not only form the initial net ns.
>
> Is this wi
On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote:
> On 07/11/17 08:29 AM, Steffen Klassert wrote:
> > Sorry for replying to old mail...
> > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx)
> > > +{
> >
> > ...
>
Sorry for replying to old mail...
On Wed, Jun 14, 2017 at 11:37:39AM -0700, Dave Watson wrote:
> +static int tls_do_encryption(struct tls_context *tls_ctx,
> + struct tls_sw_context *ctx, size_t data_len,
> + gfp_t flags)
> +{
> + unsigned int
On Thu, Apr 13, 2017 at 11:52:13AM +0200, Jason A. Donenfeld wrote:
> Allow users of padata to determine the queue length themselves, via this
> added helper function, so that we can later remove the hard-coded 1000-
> job limit. We thus add a helper function, and then move the limiting
> functiona
y: Dan Carpenter
This looks ok,
Acked-by: Steffen Klassert
he in-kernel CRYPTO_MAX_ALG_NAME value.
>
> Signed-off-by: Herbert Xu
Acked-by: Steffen Klassert
On Thu, Apr 06, 2017 at 01:58:32PM -0700, David Miller wrote:
> 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 go
is locked, call to
> list_entry is not locked, which means it's feasible that two threads
> pick up the same padata object and subsequently call list_add_tail on
> them at the same time. The fix is thus be hoist that lock outside of
> that block.
>
> Signed-off-by: Jason A. Donenfeld
Acked-by: Steffen Klassert
On Thu, Mar 23, 2017 at 12:03:43AM +0100, Jason A. Donenfeld wrote:
> Hey Steffen,
>
> WireGuard makes really heavy use of padata, feeding it units of work
> from different cores in different contexts all at the same time. For
> the most part, everything has been fine, but one particular user has
:68:26: warning: variable ‘pinst’ set but not used
> [-Wunused-but-set-variable]
>
> Also remove the now unused variable pd which is only used to set pinst.
>
> Signed-off-by: Tobias Klauser
Acked-by: Steffen Klassert
Thanks!
--
To unsubscribe from this list: send the line &qu
inux/padata.h
> +++ b/include/linux/padata.h
> @@ -3,6 +3,7 @@
> *
> * Copyright (C) 2008, 2009 secunet Security Networks AG
> * Copyright (C) 2008, 2009 Steffen Klassert
> + * Copyright (C) 2016 Jason A. Donenfeld
> *
> * This program is free software; you can redi
On Tue, Jun 21, 2016 at 04:53:21PM +0800, Herbert Xu wrote:
> Hi:
>
> I finally got around to working on this. I quickly gave up on the
> notion of hijacking the queued requests as we may end up overwhelming
> our caller.
>
> So the solution is the obvious one of using cryptd as long as there
>
Hi Jason.
On Tue, Jun 14, 2016 at 11:00:54PM +0200, Jason A. Donenfeld wrote:
> Hi Steffen & Folks,
>
> I submit a job to padata_do_parallel(). When the parallel() function
> triggers, I do some things, and then call padata_do_serial(). Finally
> the serial() function triggers, where I complete t
On Wed, May 04, 2016 at 05:52:56PM +0800, Herbert Xu wrote:
> On Wed, May 04, 2016 at 11:34:20AM +0200, Steffen Klassert wrote:
> >
> > Hmm, the 'sleeping while atomic' because of not unmapping
> > the page goes away, but now I see a lot of IPsec ICV fails
>
On Tue, May 03, 2016 at 05:55:31PM +0800, Herbert Xu wrote:
> On Thu, Apr 28, 2016 at 10:27:43AM +0200, Steffen Klassert wrote:
> >
> > The problem was that if offset (in a superpage) equals
> > PAGE_SIZE in hash_walk_next(), nbytes becomes zero. So
> > we map the page,
On Mon, Apr 25, 2016 at 06:05:27PM +0800, Herbert Xu wrote:
> On Thu, Apr 21, 2016 at 09:14:51AM +0200, Steffen Klassert wrote:
> > The network layer tries to allocate high order pages for skb_buff
> > fragments, this leads to problems if we pass such a buffer to
> > crypto b
passing them to crypto. If we try to avoid the
linearization with skb_cow_data in IPsec esp4/esp6 this incompatibility
becomes visible.
Signed-off-by: Steffen Klassert
---
Herbert, I could not find out why this PAGE_SIZE limit is in place.
So not sure if this is the right fix. Also, would it be
On Wed, Mar 30, 2016 at 09:04:03PM +, Mark McKinstry wrote:
> I've tested this patch in our scenario and I can confirm that it still
> fixes all of our issues.
I've applied the patch to the ipsec tree now.
Thanks for testing!
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Tue, Mar 15, 2016 at 01:28:01PM +0100, Steffen Klassert wrote:
> On Mon, Mar 14, 2016 at 09:52:05PM +, Mark McKinstry wrote:
> > Your patch adds a dst_release() call to my suggested fix, but this is
> > problematic because the kfree_skb() call at tx_error already tak
On Mon, Mar 14, 2016 at 09:52:05PM +, Mark McKinstry wrote:
> Your patch adds a dst_release() call to my suggested fix, but this is
> problematic because the kfree_skb() call at tx_error already takes care
> of releasing dst - via kfree_skb() > __kfree_skb() > skb_release_all() >
> skb_relea
On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
> On 19/02/16 01:19, Steffen Klassert wrote:
> > On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> >> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> >> now gets
On Wed, Feb 24, 2016 at 09:37:39PM +, Mark McKinstry wrote:
> On 19/02/16 01:19, Steffen Klassert wrote:
> > On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> >> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> >> now gets
On Thu, Feb 18, 2016 at 01:40:00AM +, Mark McKinstry wrote:
> This patch fixes our issue, thanks. In our scenario the tunnel path MTU
> now gets updated so that subsequent large packets sent over the tunnel
> get fragmented correctly.
I've applied this patch to the ipsec tree now.
Thanks for
ations like ping that don't
check for this. So add pmtu handling to vti_xmit to
report MTU changes immediately.
Signed-off-by: Steffen Klassert
---
net/ipv4/ip_vti.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 5cf10b7..68
On Mon, Dec 07, 2015 at 06:27:48AM -0500, Sowmini Varadhan wrote:
> On (12/07/15 09:40), Steffen Klassert wrote:
> >
> > I've pushed it to
> >
> > https://git.kernel.org/cgit/linux/kernel/git/klassert/linux-stk.git/log/?h=net-next-ipsec-offload
> >
>
On Thu, Dec 03, 2015 at 06:38:20AM -0500, Sowmini Varadhan wrote:
> On (12/03/15 09:45), Steffen Klassert wrote:
> > pcrypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni)))
> >
> > Result:
> >
&
On Thu, Dec 03, 2015 at 06:38:20AM -0500, Sowmini Varadhan wrote:
> On (12/03/15 09:45), Steffen Klassert wrote:
> > pcrypt(echainiv(authenc(hmac(sha1-ssse3),cbc-aes-aesni)))
> >
> > Result:
> >
&
On Wed, Dec 02, 2015 at 07:05:38AM -0500, Sowmini Varadhan wrote:
> On (12/02/15 07:53), Steffen Klassert wrote:
> >
> > I'm currently working on a GRO/GSO codepath for IPsec too. The GRO part
> > works already. I decapsulate/decrypt the packets on layer2 with a esp GRO
On Tue, Dec 01, 2015 at 12:59:53PM -0500, Sowmini Varadhan wrote:
>
> 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
> improve this. Here are m
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 -> km_state_notify -> xfrm_send_state_notify().
> Use an aligned pointer to xfrm_usersa_info for th
On Thu, Aug 13, 2015 at 05:28:52PM +0800, Herbert Xu wrote:
> Now that seqniv is identical with seqiv we no longer need it.
>
> Signed-off-by: Herbert Xu
Acked-by: Steffen Klassert
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of
todev
> > tree.
>
> The patches look fine to me. Steffen, what do you think?
I'm fine with this. If you want to merge this series through the
cryptodev tree, feel free to add a
Acked-by: Steffen Klassert
--
To unsubscribe from this list: send the line "unsubscribe linux-crypt
On Thu, May 28, 2015 at 12:18:51AM -0700, Alexander Duyck wrote:
> On 05/27/2015 10:36 PM, Steffen Klassert wrote:
> >On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
> >>This change makes it so that we use icmpv6_send to report PMTU issues back
> >>in
On Wed, May 27, 2015 at 07:16:37AM -0700, Alexander Duyck wrote:
> These patches are meant to try and address the fact the VTI tunnels are
> currently overwriting the skb->mark value. I am generally happy with the
> first two patches, however the third patch still modifies the skb->mark,
> though
On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
> This change makes it so that we use icmpv6_send to report PMTU issues back
> into tunnels in the case that the resulting packet is larger than the MTU
> of the outgoing interface. Previously xfrm_local_error was being used in
> thi
On Thu, May 28, 2015 at 12:49:19PM +0800, Herbert Xu wrote:
> On Wed, May 27, 2015 at 10:40:32AM -0700, Alexander Duyck wrote:
> > This change makes it so that we use icmpv6_send to report PMTU issues back
> > into tunnels in the case that the resulting packet is larger than the MTU
> > of the outg
On Wed, May 27, 2015 at 05:29:22PM +0800, Herbert Xu wrote:
> On Wed, May 27, 2015 at 11:25:33AM +0200, Steffen Klassert wrote:
> >
> > Not sure if I missed something in the flood of patches, but if I
> > apply your v3 patchset on top of the cryptodev tree, it crashes
>
On Wed, May 27, 2015 at 04:01:05PM +0800, Herbert Xu wrote:
> Hi:
>
> The only changes from the last version are that set_ad no longer
> takes a cryptoff argument and testmgr has been updated to always
> supply space for the authentication tag.
>
> The algif_aead patch has been removed and will b
On Tue, May 26, 2015 at 03:41:10PM -0700, Alexander Duyck wrote:
> These patches are meant to try and address the fact the VTI tunnels are
> currently overwriting the skb->mark value. I am generally happy with the
> first two patches, however the third patch still modifies the skb->mark,
> though
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
> Hi:
>
> It looks like our IPsec implementations of CCM and GCM are buggy
> in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gc
On Thu, Nov 20, 2014 at 03:45:26PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 08:11:42AM +0100, Steffen Klassert wrote:
> >
> > I think this is not sufficient, crypto_alg_match() will now return the first
> > algorithm in crypto_alg_list that matches cra_name. We
On Thu, Nov 20, 2014 at 03:43:42PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
> >
> > What about to use a fallback algorithm that does not need to touch
> > FPU/SIMD in such cases? We would not need cryptd at all and it would
On Sat, Nov 15, 2014 at 11:15:50AM +0800, Herbert Xu wrote:
> On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >
> > Everything below the local_bh_enable() should not run in atomic context
> > as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEE
On Thu, Nov 20, 2014 at 12:46:50PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 05:23:23AM +0100, Stephan Mueller wrote:
> >
> > Here is the code:
> >
> > static int crypto_report(struct sk_buff *in_skb, struct nlmsghdr *in_nlh,
> > struct nlattr **attrs)
> > {
> > ...
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
> Am Dienstag, 18. November 2014, 22:08:23 schrieb Herbert Xu:
>
> Hi Herbert, Steffen,
>
> >
> > We already have crypto_user so you should be extending that to
> > cover what's missing.
>
> After playing a bit with the interface,
On Thu, Nov 20, 2014 at 05:03:24AM +0100, Stephan Mueller wrote:
>
> Btw: is there an example that uses that interface? The ordering of data
> structures in the netlink message is not really clear from looking at the
> code.
I wrote to tool that uses this API some time ago, it is still
a bit ru
On Wed, Nov 12, 2014 at 06:41:28PM +0800, Ming Liu wrote:
> On 11/12/2014 04:41 PM, Steffen Klassert wrote:
> >On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
> >> }
> >>@@ -147,11 +149,9 @@ static void cryptd_queue_worker(struct work_struct
> &g
On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote:
> On 11/12/2014 04:51 PM, Herbert Xu wrote:
> >On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >>Can't we just use cryptd unconditionally to fix this reordering problem?
> >I think the
On Wed, Nov 12, 2014 at 04:51:48PM +0800, Herbert Xu wrote:
> On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >
> > Can't we just use cryptd unconditionally to fix this reordering problem?
>
> I think the idea is that most of the time cryptd isn&
On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
> So far, the encryption/decryption are asynchronously processed in
> softirq and cryptd which would result in a implicit order of data,
> therefore leads IPSec stack also out of order while encapsulating
> or decapsulating packets.
>
> Con
ence()
>
Both
Acked-by: Steffen Klassert
Thanks!
--
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
; Signed-off-by: Herbert Xu
>
That's fine by me.
Acked-by: Steffen Klassert
--
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
the seq_lock spinlock was never explicitly initialized -- one more
> reason to get rid of it.
>
> Signed-off-by: Mathias Krause
Acked-by: Steffen Klassert
Herbert can you take this one?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
On Fri, Aug 23, 2013 at 01:12:33PM +0200, Richard Weinberger wrote:
> padata_cpu_callback() takes pinst->lock, to avoid taking
> an uninitialized lock, register the notifier after it's
> initialization.
>
> Signed-off-by: Richard Weinberger
Looks ok,
Acked-by:
u()".
> "need add 'break' between CPU_UP_CANCELED and CPU_DOWN_FAILED".
>
>
> Signed-off-by: Chen Gang
This looks ok to me, Herbert can you take this one?
Acked-by: Steffen Klassert
--
To unsubscribe from this list: send the line "unsubscribe linu
On Thu, Aug 22, 2013 at 01:27:16PM +0800, Chen Gang wrote:
> On 08/22/2013 01:11 PM, Steffen Klassert wrote:
> > On Tue, Aug 20, 2013 at 11:44:31AM +0800, Chen Gang wrote:
> >>
> >> If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED
> >> shar
On Tue, Aug 20, 2013 at 11:44:31AM +0800, Chen Gang wrote:
>
> If this patch is correct, better to let CPU_ONLINE and CPU_DOWN_FAILED
> share the same code.
>
> And do we need a comment "/* fall through */" between CPU_UP_CANCELED
> and CPU_DOWN_FAILED (or it is another bug, need a 'break' statem
On Mon, Apr 08, 2013 at 10:48:44AM +0300, Jussi Kivilinna wrote:
> Patch adds support for NIST recommended block cipher mode CMAC to CryptoAPI.
>
> This work is based on Tom St Denis' earlier patch,
> http://marc.info/?l=linux-crypto-vger&m=135877306305466&w=2
>
> Cc: Tom St Denis
> Signed-off-
Ccing Horia Geanta, he did the esn implementation for talitos.
On Fri, Mar 08, 2013 at 03:27:48PM +, Chaoxing Lin wrote:
> 1. Can any one point me which RFC describe how exactly authencesn should work?
>
The ESN algorithm is described in RFC 4303 IP Encapsulating Security
Payload (ESP).
> 2
On Thu, Jan 24, 2013 at 01:25:46PM +0200, Jussi Kivilinna wrote:
>
> Maybe it would be cleaner to not mess with pfkeyv2.h at all, but instead mark
> algorithms that do not support pfkey with flag. See patch below.
>
As nobody seems to have another opinion, we could go either with your
approach,
On Sat, Jan 26, 2013 at 10:49:46AM +0300, Dan Carpenter wrote:
> It's testing for ->show but calling ->store().
>
> Signed-off-by: Dan Carpenter
Looks like a copy and paste error.
Acked-by: Steffen Klassert
Herbert, are you going to take this one?
Thanks!
--
To unsubs
On Thu, Jan 24, 2013 at 07:37:50AM -0500, Tom St Denis wrote:
>
> Also a question for the netdev folk, in order to be timely would it be
> acceptable to patch ah4 and then ah6 with the AEAD changes? Or would the
> team require both to be patched simultaneously?
>
We would need patches for bo
On Thu, Jan 24, 2013 at 01:25:46PM +0200, Jussi Kivilinna wrote:
>
> Maybe it would be cleaner to not mess with pfkeyv2.h at all, but instead mark
> algorithms that do not support pfkey with flag. See patch below.
>
Yes, would be an option too. I would be fine with that,
but let's here if someo
On Wed, Jan 23, 2013 at 05:35:10PM +0200, Jussi Kivilinna wrote:
>
> Problem seems to be that PFKEYv2 does not quite work with IKEv2, and
> XFRM API should be used instead. There is new numbers assigned for
> IKEv2:
> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml#ikev2-pa
(Cc net...@vger.kernel.org)
On Mon, Jan 21, 2013 at 07:57:28AM -0500, Tom St Denis wrote:
> Hey all,
>
> Here's an updated patch which addresses a couple of build issues and coding
> style complaints.
>
> I still can't get it to run via testmgr I get
>
> [ 162.407807] alg: No test for cmac
On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> I'm not sure how this patchset should be dealt with (should 1st patch go
> through different tree than 2nd and 3rd?), so therefore it's RFC.
>
> Second patch makes rfc3686 template work with asynchronous block ciphers and
> third p
On Sat, Dec 29, 2012 at 11:08:12AM +1100, Herbert Xu wrote:
> On Fri, Dec 28, 2012 at 03:23:11PM -0800, David Miller wrote:
> > From: Herbert Xu
> > Date: Sat, 29 Dec 2012 09:42:49 +1100
> >
> > > On Fri, Dec 28, 2012 at 12:04:48PM +0200, Jussi Kivilinna wrote:
> > >> I'm not sure how this patchs
On Tue, Nov 13, 2012 at 09:52:33AM +0800, Shan Wei wrote:
> From: Shan Wei
>
> For bottom halves off, __this_cpu_read is better.
>
> Signed-off-by: Shan Wei
> Reviewed-by: Christoph Lameter
Acked-by: Steffen Klassert
Herbert, are you going to take this one?
--
To uns
>
> @@ -204,8 +204,7 @@ static struct padata_priv *padata_get_next(struct
> parallel_data *pd)
> goto out;
> }
>
> - queue = per_cpu_ptr(pd->pqueue, smp_processor_id());
> - if (queue->cpu_index == next_queue->cpu_index) {
> + if (this_cpu_read(pd->pqueue->cpu_i
1 - 100 of 383 matches
Mail list logo
