From: Eyal Birger <eyal.birger@gmail.com>
To: antony.antony@secunet.com
Cc: Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
netdev@vger.kernel.org
Subject: Re: [PATCH 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input.
Date: Fri, 20 Jan 2023 13:05:04 +0200 [thread overview]
Message-ID: <CAHsH6GtgcffudgDzyTv8f8CZC13ZKMeU886DLHuuj0Tu73Ppfg@mail.gmail.com> (raw)
In-Reply-To: <6dfd03c5fa0afb99f255f4a35772df19e33880db.1674156645.git.antony.antony@secunet.com>
Hi,
On Thu, Jan 19, 2023 at 9:59 PM Antony Antony <antony.antony@secunet.com> wrote:
>
> From: Steffen Klassert <steffen.klassert@secunet.com>
>
> This is needed to support GRO for ESP in UDP encapsulation.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
> ---
> net/ipv4/esp4_offload.c | 2 +-
> net/ipv6/esp6_offload.c | 2 +-
> net/xfrm/xfrm_input.c | 75 +++++++++++++++++++++++------------------
> 3 files changed, 44 insertions(+), 35 deletions(-)
>
> diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
> index 3969fa805679..77bb01032667 100644
> --- a/net/ipv4/esp4_offload.c
> +++ b/net/ipv4/esp4_offload.c
> @@ -76,7 +76,7 @@ static struct sk_buff *esp4_gro_receive(struct list_head *head,
>
> /* We don't need to handle errors from xfrm_input, it does all
> * the error handling and frees the resources on error. */
> - xfrm_input(skb, IPPROTO_ESP, spi, -2);
> + xfrm_input(skb, IPPROTO_ESP, spi, 0);
>
> return ERR_PTR(-EINPROGRESS);
> out_reset:
> diff --git a/net/ipv6/esp6_offload.c b/net/ipv6/esp6_offload.c
> index 75c02992c520..ee5f5abdb503 100644
> --- a/net/ipv6/esp6_offload.c
> +++ b/net/ipv6/esp6_offload.c
> @@ -103,7 +103,7 @@ static struct sk_buff *esp6_gro_receive(struct list_head *head,
>
> /* We don't need to handle errors from xfrm_input, it does all
> * the error handling and frees the resources on error. */
> - xfrm_input(skb, IPPROTO_ESP, spi, -2);
> + xfrm_input(skb, IPPROTO_ESP, spi, 0);
>
> return ERR_PTR(-EINPROGRESS);
> out_reset:
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index c06e54a10540..ffd62ad58207 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -458,6 +458,35 @@ static int xfrm_inner_mode_input(struct xfrm_state *x,
> return -EOPNOTSUPP;
> }
>
> +static int xfrm_input_check_offload(struct net *net, struct sk_buff *skb,
> + struct xfrm_state *x,
> + struct xfrm_offload *xo)
> +{
> + if (!(xo->status & CRYPTO_SUCCESS)) {
> + if (xo->status &
> + (CRYPTO_TRANSPORT_AH_AUTH_FAILED |
> + CRYPTO_TRANSPORT_ESP_AUTH_FAILED |
> + CRYPTO_TUNNEL_AH_AUTH_FAILED |
> + CRYPTO_TUNNEL_ESP_AUTH_FAILED)) {
> + xfrm_audit_state_icvfail(x, skb,
> + x->type->proto);
> + x->stats.integrity_failed++;
> + XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEPROTOERROR);
> + return -EINVAL;
> + }
> +
> + if (xo->status & CRYPTO_INVALID_PROTOCOL) {
> + XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEPROTOERROR);
> + return -EINVAL;
> + }
> +
> + XFRM_INC_STATS(net, LINUX_MIB_XFRMINBUFFERERROR);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> {
> const struct xfrm_state_afinfo *afinfo;
> @@ -477,7 +506,7 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> struct xfrm_offload *xo = xfrm_offload(skb);
> struct sec_path *sp;
>
> - if (encap_type < 0) {
> + if (encap_type < 0 || (xo && xo->flags & XFRM_GRO)) {
> x = xfrm_input_state(skb);
>
> if (unlikely(x->km.state != XFRM_STATE_VALID)) {
> @@ -495,46 +524,26 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
> family = x->outer_mode.family;
>
> /* An encap_type of -1 indicates async resumption. */
> - if (encap_type == -1) {
> + if (encap_type < 0) {
Why is this specific line change needed? I see that now -2 is not sent
anymore, so how is this related?
If it is needed, maybe the comment above also needs updating?
nit, a cover letter would've been handy so that the series could be
fetched as a whole.
Eyal.
next prev parent reply other threads:[~2023-01-20 11:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 19:33 [PATCH 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input Antony Antony
2023-01-19 19:33 ` [PATCH 2/3] xfrm: Support GRO for IPv4 ESP in UDP encapsulation Antony Antony
2023-01-20 11:04 ` Eyal Birger
2023-01-19 19:34 ` [PATCH 3/3] xfrm: Support GRO for IPv6 " Antony Antony
2023-02-06 17:18 ` Pablo Neira Ayuso
2023-01-20 11:05 ` Eyal Birger [this message]
2023-08-16 9:57 ` [PATCH v4 ipsec-next 0/3] xfrm: Support GRO decapsulation for " Antony Antony
2023-08-16 9:57 ` [PATCH v4 ipsec-next 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input Antony Antony
2023-08-16 9:57 ` [PATCH v4 ipsec-next 2/3] xfrm: Support GRO for IPv4 ESP in UDP encapsulation Antony Antony
2023-08-16 11:15 ` Eyal Birger
2023-08-16 16:59 ` Antony Antony
2023-08-16 9:57 ` [PATCH v4 ipsec-next 3/3] xfrm: Support GRO for IPv6 " Antony Antony
2023-08-16 13:12 ` [PATCH v5 ipsec-next 0/3] xfrm: Support GRO decapsulation for " Antony Antony
2023-08-16 13:12 ` [PATCH v5 ipsec-next 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input Antony Antony
2023-08-16 13:13 ` [PATCH v5 ipsec-next 2/3] xfrm: Support GRO for IPv4 ESP in UDP encapsulation Antony Antony
2023-08-16 13:13 ` [PATCH v5 ipsec-next 3/3] xfrm: Support GRO for IPv6 " Antony Antony
2023-08-17 11:52 ` [PATCH v5 ipsec-next 0/3] xfrm: Support GRO decapsulation for " Eyal Birger
2023-09-26 10:14 ` Antony Antony
2023-09-26 10:15 ` [PATCH v6 ipsec-next 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input Antony Antony
2023-09-29 6:12 ` Steffen Klassert
2023-09-26 10:15 ` [PATCH v6 ipsec-next 2/3] xfrm: Support GRO for IPv4 ESP in UDP encapsulation Antony Antony
2023-09-26 10:15 ` [PATCH v6 ipsec-next 3/3] xfrm: Support GRO for IPv6 " Antony Antony
2023-09-26 13:07 ` [PATCH v5 ipsec-next 0/3] xfrm: Support GRO decapsulation for " Eyal Birger
2023-10-04 13:04 ` [PATCH v7 " Antony Antony
2023-10-04 13:05 ` [PATCH v7 ipsec-next 1/3] xfrm: Use the XFRM_GRO to indicate a GRO call on input Antony Antony
2023-10-04 13:05 ` [PATCH v7 ipsec-next 2/3] xfrm: Support GRO for IPv4 ESP in UDP encapsulation Antony Antony
2023-10-04 13:05 ` [PATCH v7 ipsec-next 3/3] xfrm: Support GRO for IPv6 " Antony Antony
2023-10-06 5:49 ` [PATCH v7 ipsec-next 0/3] xfrm: Support GRO decapsulation for " Steffen Klassert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHsH6GtgcffudgDzyTv8f8CZC13ZKMeU886DLHuuj0Tu73Ppfg@mail.gmail.com \
--to=eyal.birger@gmail.com \
--cc=antony.antony@secunet.com \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).