On Tue, Apr 20, 2021 at 1:59 AM Davide Caratti <dcara...@redhat.com> wrote:
>
> hello Cong, thanks for looking at this!
>
> On Mon, 2021-04-19 at 11:46 -0700, Cong Wang wrote:
> > On Mon, Apr 19, 2021 at 8:24 AM Davide Caratti <dcara...@redhat.com> wrote:
> > > diff --git a/net/sched/sch_frag.c b/net/sched/sch_frag.c
> > > index e1e77d3fb6c0..8c06381391d6 100644
> > > --- a/net/sched/sch_frag.c
> > > +++ b/net/sched/sch_frag.c
> > > @@ -90,16 +90,16 @@ static int sch_fragment(struct net *net, struct 
> > > sk_buff *skb,
> > >         }
> > >
> > >         if (skb_protocol(skb, true) == htons(ETH_P_IP)) {
> > > -               struct dst_entry sch_frag_dst;
> > > +               struct rtable sch_frag_rt = { 0 };
> >
> > Is setting these fields 0 sufficient here? Because normally a struct table
> > is initialized by rt_dst_alloc() which sets several of them to non-zero,
> > notably, rt->rt_type and rt->rt_uncached.
> >
> > Similar for the IPv6 part, which is initialized by rt6_info_init().
>
> for what we do now in openvswitch and sch_frag, that should be
> sufficient: a similar thing is done by br_netfilter [1], apparently for
> the same "refragmentation" purposes. On a fedora host (running 5.10, but
> it shouldn't be much different than current Linux), I just dumped
> 'fake_rtable' from a bridge device:

Sounds fair. It looks like all of these cases merely use dst->dev->mtu,
so it is overkill to pass a full dst just to satisfy some callees.

Anyway, your patch should be okay as a fix for -net.

Thanks.

Reply via email to