netdev - Re: [BUG] 2.6.29-rc* QinQ vlan trunking regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49AF8CE0.6030301@trash.net>
Date:	Thu, 05 Mar 2009 09:27:12 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Frank Blaschka <blaschka@...ux.vnet.ibm.com>
CC:	David Miller <davem@...emloft.net>, 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

Frank Blaschka wrote:
> Hi Dave, Patrick,
>
> sorry I could not follow the complete discussion of the fixes done for this problem
> but does
>
>  	if (netif_device_present(real_dev) && ops->ndo_neigh_setup)
> -		err = ops->ndo_neigh_setup(dev, pa);
> +		err = ops->ndo_neigh_setup(real_dev, pa);
>
> not change the idea of the neigh_setup? Remind we want the neigh_setup of the
> real device as the neigh setup function for the vlan device.
>   

An we still use it. The only difference is that we pass it the
correct device reference, which not only fixes the recursion,
but is also expected by the callbacks. Look at bonding or simply
vlan itself.

The setup itself is still done using the neigh_params passed to
VLAN, which appears to be what was originally intended.

--
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