I'm going to commit this patch to my tree. Hopefully, this should appear in
net-next shortly.
David
---
commit 4da137ed8a467d01f87ac84ceb2a7af8719e0136
Author: Herbert Xu
Date: Sun Jun 26 14:55:24 2016 -0700
rxrpc: Avoid using stack memory in SG lists in rxkad
rxkad uses stack me
Herbert Xu wrote:
> > I'm using the per-skb state for my own purposes and might be looking at it
> > elsewhere at the same time.
>
> AFAICS this cannot happen for secure_packet/verify_packet. In both
> cases we have exclusive ownership of the skb.
In code I'm busy working on the patch I'm decr
On Tue, Jun 28, 2016 at 10:07:44AM +0100, David Howells wrote:
>
> Since it's (more or less) a one off piece of memory, why not kmalloc it
> temporarily rather than expanding the connection struct? Also, the bit where
> you put a second rxrpc_crypt in just so that it happens to give you a 16-byte
On Tue, Jun 28, 2016 at 09:54:23AM +0100, David Howells wrote:
>
> I'm using the per-skb state for my own purposes and might be looking at it
> elsewhere at the same time.
AFAICS this cannot happen for secure_packet/verify_packet. In both
cases we have exclusive ownership of the skb.
But it's y
Herbert Xu wrote:
> Huh? If you can't write to csum_iv_head without clobbering others
> then by the same reasoning you can't write to csum_iv either. So
> unless you're saying the existing code is already broken then there
> is nothing wrong with the patch.
Ah, for some reason I read it as bein
Herbert Xu wrote:
> > I assume you're assuming that the rxrpc_skb_priv struct contents can
> > arbitrarily replaced temporarily...
>
> Of course you can, it's per-skb state.
I'm using the per-skb state for my own purposes and might be looking at it
elsewhere at the same time.
David
On Tue, Jun 28, 2016 at 08:52:20AM +0100, David Howells wrote:
> Andy Lutomirski wrote:
>
> > - skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
> > + skcipher_request_set_crypt(req, &sg, &sg, sizeof(tmpbuf), iv.x);
>
> Don't the sg's have to be different? Aren't they
Andy Lutomirski wrote:
> - skcipher_request_set_crypt(req, &sg[1], &sg[0], sizeof(tmpbuf), iv.x);
> + skcipher_request_set_crypt(req, &sg, &sg, sizeof(tmpbuf), iv.x);
Don't the sg's have to be different? Aren't they both altered by the process
of reading/writing from them?
> stru
You should also note there's a pile of rxrpc patches in net-next that might
cause your patch problems.
David
On Tue, Jun 28, 2016 at 08:32:46AM +0100, David Howells wrote:
> Andy Lutomirski wrote:
>
> > @@ -277,6 +277,7 @@ struct rxrpc_connection {
> > struct key *key; /* security for this connection
> > (client) */
> > struct key *server_key;/* security
Andy Lutomirski wrote:
> @@ -277,6 +277,7 @@ struct rxrpc_connection {
> struct key *key; /* security for this connection
> (client) */
> struct key *server_key;/* security for this service */
> struct crypto_skcipher *cipher;/*
11 matches
Mail list logo
