Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756916AbZCDLpy (ORCPT ); Wed, 4 Mar 2009 06:45:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753974AbZCDLpk (ORCPT ); Wed, 4 Mar 2009 06:45:40 -0500 Received: from stinky.trash.net ([213.144.137.162]:33717 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755554AbZCDLpi (ORCPT ); Wed, 4 Mar 2009 06:45:38 -0500 Message-ID: <49AE69DD.80802@trash.net> Date: Wed, 04 Mar 2009 12:45:33 +0100 From: Patrick McHardy User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: David Miller CC: bart@jukie.net, greearb@candelatech.com, shemminger@vyatta.com, dada1@cosmosbay.com, frank.blaschka@de.ibm.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [BUG] 2.6.29-rc* QinQ vlan trunking regression References: <20090228180541.GA729@jukie.net> <20090303.234327.81716668.davem@davemloft.net> <49AE509B.3000305@trash.net> <20090304.025914.149394356.davem@davemloft.net> In-Reply-To: <20090304.025914.149394356.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1606 Lines: 40 David Miller wrote: > From: Patrick McHardy > 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/