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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 30 Nov 2009 15:53:34 -0500 From: Andy Gospodarek <andy@...yhouse.net> To: Patrick McHardy <kaber@...sh.net> Cc: Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org, fubar@...ibm.com Subject: Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device On Mon, Nov 30, 2009 at 09:22:33PM +0100, Patrick McHardy wrote: > Andy Gospodarek wrote: > > diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c > > index e75a2f3..8d8a778 100644 > > --- a/net/8021q/vlan_core.c > > +++ b/net/8021q/vlan_core.c > > @@ -14,6 +14,7 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp, > > if (skb_bond_should_drop(skb)) > > goto drop; > > > > + skb->skb_iif = skb->dev->ifindex; > > __vlan_hwaccel_put_tag(skb, vlan_tci); > > skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK); > > > > @@ -85,6 +86,7 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp, > > if (skb_bond_should_drop(skb)) > > goto drop; > > > > + skb->skb_iif = skb->dev->ifindex; > > __vlan_hwaccel_put_tag(skb, vlan_tci); > > skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK); > > > > How about pulling the skb->iif assignment in netif_receive_skb() up > before the vlan_hwaccel_do_receive() call instead? I'm not sure how that will help. My goal with the two changes in vlan_core.c was to capture the input device index before we lost it -- which is precisely what happens when coming up through a driver like bnx2 that supports vlan acceleration: (NAPI poll) bnx2_poll bnx2_poll_work bnx2_rx_int vlan_hwaccel_receive_skb __vlan_hwaccel_rx (skb->dev set to vlan device) netif_receive_skb In that case, setting skb_iif in netif_receive_skb would be too late. The original dev would no longer be known. > I'd actually call > this a bug fix since hardware accelerated devices should not differ > from non-accelerated devices in their iif value. This dances the line between bugfix and feature since the arp monitoring component was never really advertised as working, but you are correct that it could be a bug since skb_iif should be consistent depending the the devices capabilities. -- 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