[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <77263327-2fc7-6ba0-567e-0d3643d57c2d@gmail.com>
Date: Fri, 21 Aug 2020 14:46:44 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Steffen Klassert <steffen.klassert@...unet.com>,
David Miller <davem@...emloft.net>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, netdev@...r.kernel.org
Subject: Re: [PATCH 6/6] xfrm: add espintcp (RFC 8229)
On 1/20/20 11:38 PM, Steffen Klassert wrote:
> From: Sabrina Dubroca <sd@...asysnail.net>
>
> TCP encapsulation of IKE and IPsec messages (RFC 8229) is implemented
> as a TCP ULP, overriding in particular the sendmsg and recvmsg
> operations. A Stream Parser is used to extract messages out of the TCP
> stream using the first 2 bytes as length marker. Received IKE messages
> are put on "ike_queue", waiting to be dequeued by the custom recvmsg
> implementation. Received ESP messages are sent to XFRM, like with UDP
> encapsulation
...
> +
> +static int espintcp_sendskb_locked(struct sock *sk, struct espintcp_msg *emsg,
> + int flags)
> +{
> + do {
> + int ret;
> +
> + ret = skb_send_sock_locked(sk, emsg->skb,
> + emsg->offset, emsg->len);
> + if (ret < 0)
> + return ret;
> +
> + emsg->len -= ret;
> + emsg->offset += ret;
> + } while (emsg->len > 0);
> +
> + kfree_skb(emsg->skb);
> + memset(emsg, 0, sizeof(*emsg));
> +
> + return 0;
> +}
Is there any particular reason we use kfree_skb() here instead of consume_skb() ?
Same remark for final kfree_skb() in espintcp_recvmsg()
Thanks.
Powered by blists - more mailing lists