From: Florian Westphal <fw@strlen.de>
To: David Miller <davem@davemloft.net>
Cc: fw@strlen.de, netdev@vger.kernel.org
Subject: Re: [PATCH] macvlan: fix oops with vlan-on-top and HW_VLAN_CTAG_TX lowerdev
Date: Sat, 4 Jan 2014 14:51:32 +0100 [thread overview]
Message-ID: <20140104135132.GA2106@breakpoint.cc> (raw)
In-Reply-To: <20140103.153352.166630160016412696.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Florian Westphal <fw@strlen.de>
> Date: Fri, 3 Jan 2014 12:39:04 +0100
>
> >> +static const struct header_ops vlan_passthru_header_ops = {
> >> + .create = vlan_passthru_hard_header,
> >> + .rebuild = dev_rebuild_header,
> >
> > Doesn't that result in infinite recursion when invoking
> > dev_rebuild_header() on skb whose dev->header_ops is
> > vlan_passthru_header_ops?
>
> The skb->dev should be the real_dev at this point, no?
Oh, this is fun.
I grep'd for invocations of ->rebuild() because I wanted to understand
when/where it is used.
I only found one single instance, namely
neigh_compat_output() in net/core/neighbour.c
It does
struct net_device *dev = skb->dev;
__skb_pull(skb, skb_network_offset(skb));
if (dev_hard_header(skb, dev, ntohs(skb->protocol), NULL, NULL, skb->len) < 0 &&
dev->header_ops->rebuild(skb))
return 0;
So I thought, if skb->dev is the vlan device, we would invoke
dev_rebuild_header(), which grabs skb->dev again and invokes
dev_rebuild_header again, etc. etc.
But: neigh_compat_output (suspicious name...) is only wired up in
net/ipv4/arp.c, in 'static const struct neigh_ops arp_broken_ops'.
... and arp_broken_ops is only set if dev->type is one of
ARPHRD_ROSE, ARPHRD_AX25, ARPHRD_NETROM.
Could it be that ->rebuild() is completely obsolete and could be removed
from almost all drivers (except above types)?
Archeology exercise #1 digs up 3b04ddde02c in linux.git, which
creats header_ops->rebuild, from the old dev->rebuild_header.
Exercise #2 then finds commit 275513d2e1c78 in netdev-vger-cvs.git tree.
Quote from commit message:
- dev->rebuild_header WILL DISAPPEAR. All the code
relying on its existance is wrong, though still works.
Alexey calling from 1997 ;-)
I'll do some more digging before working on this.
I've placed a BUG() in eth_rebuild_header on my workstation, lets see if
it dies 8-}
next prev parent reply other threads:[~2014-01-04 13:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-28 13:38 [PATCH] macvlan: fix oops with vlan-on-top and HW_VLAN_CTAG_TX lowerdev Florian Westphal
2013-12-29 22:01 ` David Miller
2013-12-30 10:27 ` Florian Westphal
2013-12-31 21:24 ` David Miller
2014-01-03 11:39 ` Florian Westphal
2014-01-03 20:33 ` David Miller
2014-01-04 13:51 ` Florian Westphal [this message]
2014-01-05 1:13 ` David Miller
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=20140104135132.GA2106@breakpoint.cc \
--to=fw@strlen.de \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/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.