[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+FuTSdF9p4Y61Ceucdg9OUT5nv+ieVUy7Rzkq6TUYc532jHCg@mail.gmail.com>
Date: Thu, 15 Oct 2020 15:56:45 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Xie He <xie.he.0141@...il.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
Network Development <netdev@...r.kernel.org>,
syzbot <syzbot+4a2c52677a8a1aa283cb@...kaller.appspotmail.com>,
William Tu <u9012063@...il.com>
Subject: Re: [Patch net v2] ip_gre: set dev->hard_header_len and
dev->needed_headroom properly
On Thu, Oct 15, 2020 at 3:19 PM Xie He <xie.he.0141@...il.com> wrote:
>
> On Thu, Oct 15, 2020 at 6:42 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > On Wed, Oct 14, 2020 at 10:25 PM Xie He <xie.he.0141@...il.com> wrote:
> > >
> > > Actually I think dev->type can be seen from user space. For example,
> > > when you type "ip link", it will display the link type for you. So I
> > > think it is useful to keep different dev->type labels without merging
> > > them even if they appear to have no difference.
> >
> > Ah, indeed. These constants are matched in iproute2 in lib/ll_types.c
> > to string representations.
> >
> > Good catch. Yes, then they have to stay as is.
>
> So in this case it may be better to keep dev->type as ARHPHRD_IPGRE
> for GRE devices with or without header_ops. This way we can avoid the
> need to update iproute2.
>
> We can still consider changing GRE devices in collect_md mode from
> ARPHRD_NONE to ARHPHRD_IPGRE. The original author who changed it to
> ARPHRD_NONE might assume ARHPHRD_IPGRE is for GRE devices with
> header_ops, so he felt he needed to distinguish GRE devices without
> header_ops by dev->type. However, ARHPHRD_IPGRE is actually already
> used for GRE devices with header_ops AND without header_ops. So it
> doesn't hurt to use ARHPHRD_IPGRE for GRE devices in collect_md mode,
> too. This would also make iproute2 to correctly display GRE devices in
> collect_md mode as GRE devices.
That's true. Whenever you make user visible changes there is some
chance of breakage. I'm not sure it's worth the risk here. The present
state is perhaps not ideal, but not broken.
Powered by blists - more mailing lists