netdev - Re: [PATCH net v1 1/2] net: gro: add flush check in udp_gro_receive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKgT0UfbSPO9hAiF1nKM-ZOfDD7Yq9i8M29JX-mwz_NnPQAj0g@mail.gmail.com>
Date: Mon, 15 Apr 2024 08:19:30 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Richard Gobert <richardbgobert@...il.com>, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, dsahern@...nel.org, 
	aleksander.lobakin@...el.com, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v1 1/2] net: gro: add flush check in udp_gro_receive_segment

On Mon, Apr 15, 2024 at 8:00 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Alexander Duyck wrote:
> > On Sat, Apr 13, 2024 at 11:38 AM Willem de Bruijn
> > <willemdebruijn.kernel@...il.com> wrote:
> > >
> > > Richard Gobert wrote:
> > > > GRO-GSO path is supposed to be transparent and as such L3 flush checks are
> > > > relevant to all flows which call skb_gro_receive. This patch uses the same
> > > > logic and code from tcp_gro_receive but in the relevant flow path in
> > > > udp_gro_receive_segment.
> > > >
> > > > Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
> > > > Signed-off-by: Richard Gobert <richardbgobert@...il.com>
> > >
> > > Reviewed-by: Willem de Bruijn <willemb@...gle.com>
> > >
> > > > ---
> > > >  net/ipv4/udp_offload.c | 13 ++++++++++++-
> > > >  1 file changed, 12 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > > > index 3498dd1d0694..1f4e08f43c4b 100644
> > > > --- a/net/ipv4/udp_offload.c
> > > > +++ b/net/ipv4/udp_offload.c
> > > > @@ -471,6 +471,7 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
> > > >       struct sk_buff *p;
> > > >       unsigned int ulen;
> > > >       int ret = 0;
> > > > +     int flush;
> > > >
> > > >       /* requires non zero csum, for symmetry with GSO */
> > > >       if (!uh->check) {
> > > > @@ -528,7 +529,17 @@ static struct sk_buff *udp_gro_receive_segment(struct list_head *head,
> > > >                               skb_gro_postpull_rcsum(skb, uh,
> > > >                                                      sizeof(struct udphdr));
> > > >
> > > > -                             ret = skb_gro_receive(p, skb);
> > > > +                             flush = NAPI_GRO_CB(p)->flush;
> > > > +
> > > > +                             if (NAPI_GRO_CB(p)->flush_id != 1 ||
> > > > +                                 NAPI_GRO_CB(p)->count != 1 ||
> > > > +                                 !NAPI_GRO_CB(p)->is_atomic)
> > > > +                                     flush |= NAPI_GRO_CB(p)->flush_id;
> > > > +                             else
> > > > +                                     NAPI_GRO_CB(p)->is_atomic = false;
> > > > +
> > > > +                             if (flush || skb_gro_receive(p, skb))
> > > > +                                     ret = 1;
> > >
> > > UDP_L4 does not have the SKB_GSO_TCP_FIXEDID that uses is_atomic as
> > > input.
> > >
> > > And I still don't fully internalize the flush_id logic after staring
> > > at it for more than one coffee.
> >
> > The flush_id field is there to indicate the difference between the
> > current IPv4 ID of the previous IP header. It is meant to be used in
> > conjunction with the is_atomic for the frame coalescing. Basically
> > after the second frame we can decide the pattern either incrementing
> > IPv4 ID or fixed, so on frames 3 or later we can decide to drop the
> > frame if it doesn't follow that pattern.
> >
> > > But even ignoring those, the flush signal of NAPI_GRO_CB(p)->flush
> > > set the network layer must be followed, so ACK. Thanks for the fix.
> >
> > I'm not sure about the placement of this code though. That is the one
> > thing that seems off to me. Specifically this seems like it should be
> > done before we start the postpull, not after. It should be something
> > that can terminate the flow before we attempt to aggregate the UDP
> > headers.
>
> In principle agreed that we should conclude the flush checks before
> doing prep for coalescing.
>
> In practice it does not matter? NAPI_GRO_CB(skb)->csum will be ignored
> if the packet gets flushed.

I was referring more to the fact that this code is one of two
branches. So there is this path, and then the is_flist branch that
comes before this. I would think this logic would apply to both
wouldn't it? I am not familiar with the code so I cannot say for
certain if it does or doesn't. If it doesn't then yes. I suppose it
doesn't matter.