All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dongseok Yi" <dseok.yi@samsung.com>
To: "'Willem de Bruijn'" <willemdebruijn.kernel@gmail.com>
Cc: "'Alexei Starovoitov'" <ast@kernel.org>,
	"'Daniel Borkmann'" <daniel@iogearbox.net>,
	"'Andrii Nakryiko'" <andrii@kernel.org>,
	"'Martin KaFai Lau'" <kafai@fb.com>,
	"'Song Liu'" <songliubraving@fb.com>,
	"'Yonghong Song'" <yhs@fb.com>,
	"'John Fastabend'" <john.fastabend@gmail.com>,
	"'KP Singh'" <kpsingh@kernel.org>,
	"'David S. Miller'" <davem@davemloft.net>,
	"'Jakub Kicinski'" <kuba@kernel.org>,
	"'Network Development'" <netdev@vger.kernel.org>,
	"'bpf'" <bpf@vger.kernel.org>,
	"'LKML'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH bpf v2] bpf: check BPF_F_ADJ_ROOM_FIXED_GSO when upgrading mss in 6 to 4
Date: Wed, 12 May 2021 15:56:14 +0900	[thread overview]
Message-ID: <01f901d746fb$e683ec60$b38bc520$@samsung.com> (raw)
In-Reply-To: <CAF=yD-+8676QHiKD2ZA4e0kVE+11cOi6sa+M-vmx0+05tm1GfQ@mail.gmail.com>

On Tue, May 11, 2021 at 01:42:46PM -0400, Willem de Bruijn wrote:
> On Tue, May 11, 2021 at 2:51 AM Dongseok Yi <dseok.yi@samsung.com> wrote:
> >
> > In the forwarding path GRO -> BPF 6 to 4 -> GSO for TCP traffic, the
> > coalesced packet payload can be > MSS, but < MSS + 20.
> > bpf_skb_proto_6_to_4 will increase the MSS and it can be > the payload
> > length. After then tcp_gso_segment checks for the payload length if it
> > is <= MSS. The condition is causing the packet to be dropped.
> >
> > tcp_gso_segment():
> >         [...]
> >         mss = skb_shinfo(skb)->gso_size;
> >         if (unlikely(skb->len <= mss))
> >                 goto out;
> >         [...]
> >
> > Allow to increase MSS when BPF_F_ADJ_ROOM_FIXED_GSO is not set.
> >
> > Fixes: 6578171a7ff0 (bpf: add bpf_skb_change_proto helper)
> > Signed-off-by: Dongseok Yi <dseok.yi@samsung.com>
> >
> > ---
> 
> Thanks. Note that this feature does not preclude the alternatives
> discussed, of converting the packet to non-TSO (by clearing gso_size)
> or optionally modifying MSS (but that should get okay from TCP
> experts).
> 
> I would target this for bpf-next and drop the Fixes. But that is
> admittedly debatable.

No problem. We can make a better decision under bpf-next.

> 
> >  net/core/filter.c | 13 +++++++------
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > v2:
> > per Willem de Bruijn request,
> > checked the flag instead of a generic approach.
> >
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index cae56d0..a98b28d 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -3276,7 +3276,7 @@ static int bpf_skb_proto_4_to_6(struct sk_buff *skb)
> >         return 0;
> >  }
> >
> > -static int bpf_skb_proto_6_to_4(struct sk_buff *skb)
> > +static int bpf_skb_proto_6_to_4(struct sk_buff *skb, u64 flags)
> >  {
> >         const u32 len_diff = sizeof(struct ipv6hdr) - sizeof(struct iphdr);
> >         u32 off = skb_mac_header_len(skb);
> > @@ -3305,7 +3305,8 @@ static int bpf_skb_proto_6_to_4(struct sk_buff *skb)
> >                 }
> >
> >                 /* Due to IPv4 header, MSS can be upgraded. */
> > -               skb_increase_gso_size(shinfo, len_diff);
> > +               if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO))
> > +                       skb_increase_gso_size(shinfo, len_diff);
> >                 /* Header must be checked, and gso_segs recomputed. */
> >                 shinfo->gso_type |= SKB_GSO_DODGY;
> >                 shinfo->gso_segs = 0;
> > @@ -3317,7 +3318,7 @@ static int bpf_skb_proto_6_to_4(struct sk_buff *skb)
> >         return 0;
> >  }
> >
> > -static int bpf_skb_proto_xlat(struct sk_buff *skb, __be16 to_proto)
> > +static int bpf_skb_proto_xlat(struct sk_buff *skb, __be16 to_proto, u64 flags)
> >  {
> >         __be16 from_proto = skb->protocol;
> >
> > @@ -3327,7 +3328,7 @@ static int bpf_skb_proto_xlat(struct sk_buff *skb, __be16 to_proto)
> >
> >         if (from_proto == htons(ETH_P_IPV6) &&
> >               to_proto == htons(ETH_P_IP))
> > -               return bpf_skb_proto_6_to_4(skb);
> > +               return bpf_skb_proto_6_to_4(skb, flags);
> >
> >         return -ENOTSUPP;
> >  }
> > @@ -3337,7 +3338,7 @@ BPF_CALL_3(bpf_skb_change_proto, struct sk_buff *, skb, __be16, proto,
> >  {
> >         int ret;
> >
> > -       if (unlikely(flags))
> > +       if (unlikely(flags & ~(BPF_F_ADJ_ROOM_FIXED_GSO)))
> >                 return -EINVAL;
> 
> Once allowing this flag, please immediately support it for both
> bpf_skb_proto_6_to_4 and bpf_skb_4_to_6.
> 
> We cannot do that later if we ignore the second case now.

I will make v3 for both 6_to_4 and 4_to_6.

> 
> 
> >         /* General idea is that this helper does the basic groundwork
> > @@ -3357,7 +3358,7 @@ BPF_CALL_3(bpf_skb_change_proto, struct sk_buff *, skb, __be16, proto,
> >          * that. For offloads, we mark packet as dodgy, so that headers
> >          * need to be verified first.
> >          */
> > -       ret = bpf_skb_proto_xlat(skb, proto);
> > +       ret = bpf_skb_proto_xlat(skb, proto, flags);
> >         bpf_compute_data_pointers(skb);
> >         return ret;
> >  }
> > --
> > 2.7.4
> >


  reply	other threads:[~2021-05-12  6:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210429102143epcas2p4c8747c09a9de28f003c20389c050394a@epcas2p4.samsung.com>
2021-04-29 10:08 ` [PATCH bpf] bpf: check for data_len before upgrading mss when 6 to 4 Dongseok Yi
2021-05-05 20:55   ` Daniel Borkmann
2021-05-06  0:45     ` Dongseok Yi
2021-05-06  1:45       ` Willem de Bruijn
2021-05-06  2:27         ` Dongseok Yi
2021-05-06 18:21           ` Willem de Bruijn
2021-05-07  0:53             ` Dongseok Yi
2021-05-07  1:25               ` Willem de Bruijn
2021-05-07  1:45                 ` Yunsheng Lin
2021-05-07  1:53                   ` Willem de Bruijn
2021-05-07  8:25                     ` Dongseok Yi
2021-05-07  9:11                       ` Yunsheng Lin
2021-05-07 10:36                         ` Dongseok Yi
2021-05-07 13:50                       ` Willem de Bruijn
2021-05-10  2:22                         ` Dongseok Yi
2021-05-10 13:19                           ` Willem de Bruijn
2021-05-10 13:46                             ` Willem de Bruijn
2021-05-11  1:11                               ` Dongseok Yi
2021-05-11 17:38                                 ` Willem de Bruijn
2021-05-12  0:45                                   ` Dongseok Yi
     [not found]   ` <CGME20210511065056epcas2p1788505019deb274f5c57650a2f5d7ef0@epcas2p1.samsung.com>
2021-05-11  6:36     ` [PATCH bpf v2] bpf: check BPF_F_ADJ_ROOM_FIXED_GSO when upgrading mss in " Dongseok Yi
2021-05-11 17:42       ` Willem de Bruijn
2021-05-12  6:56         ` Dongseok Yi [this message]
     [not found]       ` <CGME20210512074058epcas2p35536c27bdfafaa6431e164c142007f96@epcas2p3.samsung.com>
2021-05-12  7:27         ` [PATCH bpf-next v3] bpf: check for BPF_F_ADJ_ROOM_FIXED_GSO when bpf_skb_change_proto Dongseok Yi
2021-05-12 14:13           ` Willem de Bruijn
2021-05-18 20:10           ` patchwork-bot+netdevbpf

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='01f901d746fb$e683ec60$b38bc520$@samsung.com' \
    --to=dseok.yi@samsung.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=willemdebruijn.kernel@gmail.com \
    --cc=yhs@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.