On Wed, Nov 4, 2020 at 2:30 PM Oliver Herms
<oliver.peter.he...@gmail.com> wrote:
>
> On 03.11.20 19:42, Willem de Bruijn wrote:
> > Thanks. Yes, this is long overdue.
> >
> > The hard_header_len issue was also recently discussed in the context
> > of GRE in commit fdafed459998 ("ip_gre: set dev->hard_header_len and
> > dev->needed_headroom properly").
> >
> > Question is whether we should reserve room in needed_headroom instead.
> > AFAIK this existing update logic in ip6_tnl_xmit is sufficient
> >
> > "
> > /* Calculate max headroom for all the headers and adjust
> > * needed_headroom if necessary.
> > */
> > max_headroom = LL_RESERVED_SPACE(dst->dev) + sizeof(struct ipv6hdr)
> > + dst->header_len + t->hlen;
> > if (max_headroom > dev->needed_headroom)
> > dev->needed_headroom = max_headroom;
> > "I think that's enough. At least it definitely works in my test and prod
> > environment.
> Would be good to get another opinion on this though.
Sit should behave the same as other tunnels. At least in ip6_tunnel.c
and ip6_gre.c I do not see explicit initialization of needed_headroom.
> >> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
> >
> > How did you arrive at this SHA1?
> I think the legacy usage of hard_header_len in ipv6/sit.c was overseen in
> c54419321455.
> Please correct me if I'm wrong.
I don't see anything in that patch assign or modify hard_header_len.
