[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49AE69DD.80802@trash.net>
Date: Wed, 04 Mar 2009 12:45:33 +0100
From: Patrick McHardy <kaber@...sh.net>
To: David Miller <davem@...emloft.net>
CC: bart@...ie.net, greearb@...delatech.com, shemminger@...tta.com,
dada1@...mosbay.com, frank.blaschka@...ibm.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] 2.6.29-rc* QinQ vlan trunking regression
David Miller wrote:
> From: Patrick McHardy <kaber@...sh.net>
> Date: Wed, 04 Mar 2009 10:57:47 +0100
>
>>>> I can reproduce it reliably with:
>>>>
>>>> $ modprobe 8021q
>>>> $ vconfig add eth1 5
>>>> $ ifconfig eth1.5 up
>>>> $ vconfig add eth1.5 4
>>> Stephen please fix this.
>> I'm maintaining vlan :) I haven't been able to look into this yet,
>> but I should be later today.
>
> Ok, I don't actually care who fixes it :-)
>
> I asked Stephen because this appears like it might be netdev_ops
> fallout.
Good point. I think I know whats happening. The VLAN devices are
registered with vlan_netdev_ops, the ->init function then potentially
replaces them based on whether the underlying device supports HW
acceleration. At this point the register_netdev() function already
has used the first netdev_ops structure to initialize the compat
pointers, meaning the new assignment is largely without effect and
causes incorrect ops to be used with HW acceleration
This probably causes the slab corruption since the HW accelerated
VLAN device doesn't increase the headroom, but the non-accelerated
functions try to add a hard header anyways.
This is a bit tricky to fix since we actually need some valid
ops before invoking ->init(). One way would be to move the compat
ops initialization to a seperate function and have VLAN use it to
switch its ops.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists