| Message ID | 311b59aee7d648c6124a84b5ca06ac60@dondevamos.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
Le mercredi 16 juin 2010 à 10:49 +0200, Pedro Garcia a écrit : > On Mon, 14 Jun 2010 21:12:52 +0200, Eric Dumazet <eric.dumazet@gmail.com> > > Good luck for your first patch ! > > Here it is again. I added the modifications in http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 for HW accelerated incoming packets (it did not apply cleanly on the last version of > the kernel, so I applied manually). Now, if the VLAN 0 is not explicitly created by the user, VLAN 0 packets will be treated as no VLAN (802.1p packets), instead of dropping them. > > The patch is now for two files: vlan_core (accel) and vlan_dev (non accel) > > I can not test on HW accelerated devices, so if someone can check it I will appreciate (even though in the thread above it looked like yes). For non accel I tessted in 2.6.26. Now the patch is for > net-next-2.6, and it compiles OK, but I a have to setup a test environment to check it is still OK (should, but better to test). > > Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com> OK, the patch itself is correct. Now, could you please send it again with a proper changelog ? In this changelog, please explain why patch is needed, and keep lines short (< 72 chars), like the one you did in your first mail. I'll then add my Signed-off-by, since I wrote the accelerated part ;) Note : I wonder if another patch is needed, in case 8021q module is _not_ loaded. We probably should accept vlan 0 frames in this case ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric Dumazet wrote: > Le mercredi 16 juin 2010 à 10:49 +0200, Pedro Garcia a écrit : >> Here it is again. I added the modifications in http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 for HW accelerated incoming packets (it did not apply cleanly on the last version of >> the kernel, so I applied manually). Now, if the VLAN 0 is not explicitly created by the user, VLAN 0 packets will be treated as no VLAN (802.1p packets), instead of dropping them. >> >> The patch is now for two files: vlan_core (accel) and vlan_dev (non accel) >> >> I can not test on HW accelerated devices, so if someone can check it I will appreciate (even though in the thread above it looked like yes). For non accel I tessted in 2.6.26. Now the patch is for >> net-next-2.6, and it compiles OK, but I a have to setup a test environment to check it is still OK (should, but better to test). >> >> Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com> >> > > OK, the patch itself is correct. > Yes, looks fine to me as well. > Now, could you please send it again with a proper changelog ? > > In this changelog, please explain why patch is needed, and > keep lines short (< 72 chars), like the one you did in your first mail. > > I'll then add my Signed-off-by, since I wrote the accelerated part ;) > > Note : I wonder if another patch is needed, in case 8021q module is > _not_ loaded. We probably should accept vlan 0 frames in this case ? > I agree that this would be best for consistency, but that would mean adding more special cases to __netif_receive_skb(). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 16 Jun 2010 13:42:16 +0200, Patrick McHardy <kaber@trash.net> wrote: > Eric Dumazet wrote: >> Le mercredi 16 juin 2010 à 10:49 +0200, Pedro Garcia a écrit : >>> Here it is again. I added the modifications in >>> http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 for HW >>> accelerated incoming packets (it did not apply cleanly on the last >>> version of >>> the kernel, so I applied manually). Now, if the VLAN 0 is not >>> explicitly created by the user, VLAN 0 packets will be treated as no >>> VLAN (802.1p packets), instead of dropping them. >>> >>> The patch is now for two files: vlan_core (accel) and vlan_dev (non >>> accel) >>> >>> I can not test on HW accelerated devices, so if someone can check it I >>> will appreciate (even though in the thread above it looked like yes). >>> For non accel I tessted in 2.6.26. Now the patch is for >>> net-next-2.6, and it compiles OK, but I a have to setup a test >>> environment to check it is still OK (should, but better to test). >>> >>> Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com> >>> >> >> OK, the patch itself is correct. >> > > Yes, looks fine to me as well. > >> Now, could you please send it again with a proper changelog ? >> >> In this changelog, please explain why patch is needed, and >> keep lines short (< 72 chars), like the one you did in your first mail. >> >> I'll then add my Signed-off-by, since I wrote the accelerated part ;) >> >> Note : I wonder if another patch is needed, in case 8021q module is >> _not_ loaded. We probably should accept vlan 0 frames in this case ? >> > > I agree that this would be best for consistency, but that would mean > adding more special cases to __netif_receive_skb(). In my understanding, 802.1p is a "subset" of 802.1q, and they share the protocol number. We can do a 802.1p module, but in the end it will end up reusing most of the code in 802.1q. In any case defining a VLAN 0 ends up usually in problems with which table the ARP entries get stored in. This patch solves the problem to whom is not using VLAN 0 explicitly, but if somebody is using VLAN 0 tagging it will work (whatever "work" means) as before. Probably a definitive fix would be not to allow the definition of VLAN 0 in 802.1q module and provide some other way to tag priority packets without using a subinterface (maybe in the same module or a new 8021p one). I am having a look at the kernel to see what happens if we load two modules for the same protocol. By the way, the changelog I have to write is just the text before the patch? Pedro -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 16 June 2010, Pedro Garcia wrote: > Probably a definitive fix would be not to allow the definition of VLAN 0 > in 802.1q module and provide some other way to tag priority packets without > using a subinterface (maybe in the same module or a new 8021p one). I am > having a look at the kernel to see what happens if we load two modules for > the same protocol. On a related note, we will also need to support 802.1Qad provider bridges at some point, which use yet another variation of the VLAN header (actually two nested VLAN tags) with a different ethertype. I need this for 802.1Qbg multi-channel VEPA (possibly also 802.1Qbh port extenders), but I have not yet investigated how to implement this in the VLAN module. > By the way, the changelog I have to write is just the text before the > patch? Yes. Arnd -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le mercredi 16 juin 2010 à 15:28 +0200, Pedro Garcia a écrit : > > In my understanding, 802.1p is a "subset" of 802.1q, and they share the > protocol number. We can do a 802.1p module, but in the end it will end > up reusing most of the code in 802.1q. > I was more thinking of a default ETH_P_8021Q rx handler (aka vlan_skb_recv_minimal) with minimum handling (only accept vid=0 frames), being overridden by real 8021q handler if module loaded/present. > In any case defining a VLAN 0 ends up usually in problems with which table > the ARP entries get stored in. This patch solves the problem to whom > is not using VLAN 0 explicitly, but if somebody is using VLAN 0 tagging > it will work (whatever "work" means) as before. > > Probably a definitive fix would be not to allow the definition of VLAN 0 > in 802.1q module and provide some other way to tag priority packets without > using a subinterface (maybe in the same module or a new 8021p one). I am > having a look at the kernel to see what happens if we load two modules for > the same protocol. > > By the way, the changelog I have to write is just the text before the > patch? Yes, you can take a look on any patch around for examples, like... git show 6e327c11a91d190650df9aabe7d3694d4838bfa1 Check Documentation/SubmittingPatches section 2) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann wrote: > On Wednesday 16 June 2010, Pedro Garcia wrote: > >> Probably a definitive fix would be not to allow the definition of VLAN 0 >> in 802.1q module and provide some other way to tag priority packets without >> using a subinterface (maybe in the same module or a new 8021p one). I am >> having a look at the kernel to see what happens if we load two modules for >> the same protocol. >> > > On a related note, we will also need to support 802.1Qad provider bridges > at some point, which use yet another variation of the VLAN header (actually > two nested VLAN tags) with a different ethertype. > I need this for 802.1Qbg multi-channel VEPA (possibly also 802.1Qbh > port extenders), but I have not yet investigated how to implement this > in the VLAN module. > Since we don't have any special VLAN handling in the bridging code, I guess it comes down to optionally using a different ethertype value (0x88a8) in the VLAN code. We probably also need some indication from device drivers whether they are able to add these headers to avoid trying to offload tagging in case they're not. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 16 June 2010 17:28:23 Patrick McHardy wrote: > Since we don't have any special VLAN handling in the bridging code, I > guess it comes down to optionally using a different ethertype value > (0x88a8) in the VLAN code. We probably also need some indication from > device drivers whether they are able to add these headers to avoid > trying to offload tagging in case they're not. It's probably a little more than just supporting the new ethertype, but not much. The outer tag can be handled like our current VLAN module does, but the standard does not allow a regular frame to be encapsulated directly, but rather requires one of 1. In 802.1ad: an 802.1Q VLAN tag (ethertype 0x8100) followed by the frame 2. In 802.1ah: A service tag (ethertype 0x88e7) followed by the 802.1Q VLAN tag and then the frame. Maybe what we can do is extend the vlan code to understand all three frame formats (q, ad and ah) or at least the first two so we configure both the provider VID and the Customer VID for the interface in case of 802.1ad but only the regular VID in 802.1Q. Device drivers can then flag whether they support both formats or just the regular Q tag. Arnd -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 16 Jun 2010 10:49:27 +0200, Pedro Garcia <pedro.netdev@dondevamos.com> wrote: > On Mon, 14 Jun 2010 21:12:52 +0200, Eric Dumazet <eric.dumazet@gmail.com> > wrote: >> Le lundi 14 juin 2010 à 19:11 +0200, Patrick McHardy a écrit : >>> Ben Hutchings wrote: >>> > On Mon, 2010-06-14 at 18:49 +0200, Pedro Garcia wrote: >>> > >>> >> On Sun, 13 Jun 2010 22:56:30 +0100, Ben Hutchings >>> >> <bhutchings@solarflare.com> wrote: >>> >> >>> >>> I have no particular opinion on this change, but you need to read >>> >>> and >>> >>> follow Documentation/SubmittingPatches. >>> >>> >>> >>> Ben. >>> >>> >>> >> Sorry, first kernel patch, and I did not know about it. I resubmit >>> >> with >>> >> the correct style / format: >>> >> >>> > [...] >>> > >>> > Sorry, no you haven't. >>> > >>> > - Networking changes go through David Miller's net-next-2.6 tree so >>> > you >>> > need to use that as the baseline, not 2.6.26 >>> > - Patches should be applicable with -p1, not -p0 (so if you use diff, >>> > you should run it from one directory level up) >>> > - The patch was word-wrapped >>> >>> Additionally: >>> >>> - please use the proper comment style, meaning each line begins >>> with a '*' >>> >>> - the pr_debug statements may be useful for debugging, but are >>> a bit excessive for the final version >>> >>> - + /* 2010-06-13: Pedro Garcia >>> >>> We have changelogs for this, simply explaining what the code >>> does is enough. >>> >>> - Please CC the maintainer (which is me) >>> -- >> >> Pedro, we have two kind of vlan setups : >> >> accelerated and non accelerated ones. >> >> Your patch address non accelated ones only, since you only touch >> vlan_skb_recv() >> >> Accelerated vlan can follow these paths : >> >> 1) NAPI devices >> >> vlan_gro_receive() -> vlan_gro_common() >> >> 2) non NAPI devices >> >> __vlan_hwaccel_rx() >> >> So you might also patch __vlan_hwaccel_rx() and vlan_gro_common() >> >> Please merge following bits to your patch submission : >> >> http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 >> >> >> Good luck for your first patch ! > > Here it is again. I added the modifications in > http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 for HW > accelerated incoming packets (it did not apply cleanly on the last version > of > the kernel, so I applied manually). Now, if the VLAN 0 is not explicitly > created by the user, VLAN 0 packets will be treated as no VLAN (802.1p > packets), instead of dropping them. > > The patch is now for two files: vlan_core (accel) and vlan_dev (non accel) > > I can not test on HW accelerated devices, so if someone can check it I > will appreciate (even though in the thread above it looked like yes). For > non accel I tessted in 2.6.26. Now the patch is for > net-next-2.6, and it compiles OK, but I a have to setup a test environment > to check it is still OK (should, but better to test). > I tested the pacth under net-next-2.6, and it OOPSed the kernel (worked under 2.6.26 but not under 2.6.35). I have found why and solved it, but now, to my surprise, it only works when I leave the interface in promiscuous mode. After a lot of debugging, looks like the skb does not even arrive to __netif_receive_skb, unless in promiscuous mode. Under what circunstances could this happen? Pedro -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Opps... Sorry. Wrong thread. :) Pls., discard! > -----Original Message----- > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On > Behalf Of Vladislav Zolotarov > Sent: Thursday, July 08, 2010 3:55 PM > To: Pedro Garcia; netdev@vger.kernel.org > Cc: Patrick McHardy; Ben Hutchings; Eric Dumazet > Subject: RE: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" > (802.1p packet) > > Margaret, > In order to keep exploring this we need the following data: > 1. What is the scenario exactly? What is vMotion? Which kind of operation > does it do? Which kind of traffic does it pass? > 2. What is the nature of the failure- driver hang? PSOD? Loss of traffic? > 3. We need a grcdump after the failure. > > Thanks, > vlad > > > -----Original Message----- > > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On > > Behalf Of Pedro Garcia > > Sent: Wednesday, June 16, 2010 11:49 AM > > To: netdev@vger.kernel.org > > Cc: Patrick McHardy; Ben Hutchings; Eric Dumazet > > Subject: Re: [PATCH] vlan_dev: VLAN 0 should be treated as "no vlan tag" > > (802.1p packet) > > > > On Mon, 14 Jun 2010 21:12:52 +0200, Eric Dumazet <eric.dumazet@gmail.com> > > wrote: > > > Le lundi 14 juin 2010 à 19:11 +0200, Patrick McHardy a écrit : > > >> Ben Hutchings wrote: > > >> > On Mon, 2010-06-14 at 18:49 +0200, Pedro Garcia wrote: > > >> > > > >> >> On Sun, 13 Jun 2010 22:56:30 +0100, Ben Hutchings > > >> >> <bhutchings@solarflare.com> wrote: > > >> >> > > >> >>> I have no particular opinion on this change, but you need to read > and > > >> >>> follow Documentation/SubmittingPatches. > > >> >>> > > >> >>> Ben. > > >> >>> > > >> >> Sorry, first kernel patch, and I did not know about it. I resubmit > > >> >> with > > >> >> the correct style / format: > > >> >> > > >> > [...] > > >> > > > >> > Sorry, no you haven't. > > >> > > > >> > - Networking changes go through David Miller's net-next-2.6 tree so > you > > >> > need to use that as the baseline, not 2.6.26 > > >> > - Patches should be applicable with -p1, not -p0 (so if you use diff, > > >> > you should run it from one directory level up) > > >> > - The patch was word-wrapped > > >> > > >> Additionally: > > >> > > >> - please use the proper comment style, meaning each line begins > > >> with a '*' > > >> > > >> - the pr_debug statements may be useful for debugging, but are > > >> a bit excessive for the final version > > >> > > >> - + /* 2010-06-13: Pedro Garcia > > >> > > >> We have changelogs for this, simply explaining what the code > > >> does is enough. > > >> > > >> - Please CC the maintainer (which is me) > > >> -- > > > > > > Pedro, we have two kind of vlan setups : > > > > > > accelerated and non accelerated ones. > > > > > > Your patch address non accelated ones only, since you only touch > > > vlan_skb_recv() > > > > > > Accelerated vlan can follow these paths : > > > > > > 1) NAPI devices > > > > > > vlan_gro_receive() -> vlan_gro_common() > > > > > > 2) non NAPI devices > > > > > > __vlan_hwaccel_rx() > > > > > > So you might also patch __vlan_hwaccel_rx() and vlan_gro_common() > > > > > > Please merge following bits to your patch submission : > > > > > > http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 > > > > > > > > > Good luck for your first patch ! > > > > Here it is again. I added the modifications in > > http://kerneltrap.org/mailarchive/linux-netdev/2010/5/23/6277868 for HW > > accelerated incoming packets (it did not apply cleanly on the last version > of > > the kernel, so I applied manually). Now, if the VLAN 0 is not explicitly > > created by the user, VLAN 0 packets will be treated as no VLAN (802.1p > > packets), instead of dropping them. > > > > The patch is now for two files: vlan_core (accel) and vlan_dev (non accel) > > > > I can not test on HW accelerated devices, so if someone can check it I will > > appreciate (even though in the thread above it looked like yes). For non > > accel I tessted in 2.6.26. Now the patch is for > > net-next-2.6, and it compiles OK, but I a have to setup a test environment > to > > check it is still OK (should, but better to test). > > > > Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com> > > -- > > diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c > > index 50f58f5..daaca31 100644 > > --- a/net/8021q/vlan_core.c > > +++ b/net/8021q/vlan_core.c > > @@ -8,6 +8,9 @@ > > int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp, > > u16 vlan_tci, int polling) > > { > > + struct net_device *vlan_dev; > > + u16 vlan_id; > > + > > if (netpoll_rx(skb)) > > return NET_RX_DROP; > > > > @@ -16,10 +19,14 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct > > vlan_group *grp, > > > > 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); > > + vlan_id = vlan_tci & VLAN_VID_MASK; > > + vlan_dev = vlan_group_get_device(grp, vlan_id); > > > > - if (!skb->dev) > > - goto drop; > > + if (vlan_dev) > > + skb->dev = vlan_dev; > > + else > > + if (vlan_id) > > + goto drop; > > > > return (polling ? netif_receive_skb(skb) : netif_rx(skb)); > > > > @@ -82,16 +89,22 @@ vlan_gro_common(struct napi_struct *napi, struct > > vlan_group *grp, > > unsigned int vlan_tci, struct sk_buff *skb) > > { > > struct sk_buff *p; > > + struct net_device *vlan_dev; > > + u16 vlan_id; > > > > if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master))) > > skb->deliver_no_wcard = 1; > > > > 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); > > - > > - if (!skb->dev) > > - goto drop; > > + vlan_id = vlan_tci & VLAN_VID_MASK; > > + vlan_dev = vlan_group_get_device(grp, vlan_id); > > + > > + if (vlan_dev) > > + skb->dev = vlan_dev; > > + else > > + if (vlan_id) > > + goto drop; > > > > for (p = napi->gro_list; p; p = p->next) { > > NAPI_GRO_CB(p)->same_flow = > > diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c > > index 5298426..65512c3 100644 > > --- a/net/8021q/vlan_dev.c > > +++ b/net/8021q/vlan_dev.c > > @@ -142,6 +142,7 @@ int vlan_skb_recv(struct sk_buff *skb, struct > net_device > > *dev, > > { > > struct vlan_hdr *vhdr; > > struct vlan_rx_stats *rx_stats; > > + struct net_device *vlan_dev; > > u16 vlan_id; > > u16 vlan_tci; > > > > @@ -157,8 +158,18 @@ int vlan_skb_recv(struct sk_buff *skb, struct > net_device > > *dev, > > vlan_id = vlan_tci & VLAN_VID_MASK; > > > > rcu_read_lock(); > > - skb->dev = __find_vlan_dev(dev, vlan_id); > > - if (!skb->dev) { > > + vlan_dev = __find_vlan_dev(dev, vlan_id); > > + > > + /* If the VLAN device is defined, we use it. > > + * If not, and the VID is 0, it is a 802.1p packet (not > > + * really a VLAN), so we will just netif_rx it later to the > > + * original interface, but with the skb->proto set to the > > + * wrapped proto: we do nothing here. > > + */ > > + > > + if (vlan_dev) { > > + skb->dev = vlan_dev; > > + } else if (vlan_id) { > > pr_debug("%s: ERROR: No net_device for VID: %u on dev: > %s\n", > > __func__, vlan_id, dev->name); > > goto err_unlock; > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe netdev" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > N�����r��y���b�X��ǧv�^�){.n�+���z�^�)���w* > jg��� �����ݢj/���z�ޖ��2�ޙ���&�)ߡ�a���� �G���h��j:+v���w�٥
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c index 50f58f5..daaca31 100644 --- a/net/8021q/vlan_core.c +++ b/net/8021q/vlan_core.c @@ -8,6 +8,9 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp, u16 vlan_tci, int polling) { + struct net_device *vlan_dev; + u16 vlan_id; + if (netpoll_rx(skb)) return NET_RX_DROP; @@ -16,10 +19,14 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp, 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); + vlan_id = vlan_tci & VLAN_VID_MASK; + vlan_dev = vlan_group_get_device(grp, vlan_id); - if (!skb->dev) - goto drop; + if (vlan_dev) + skb->dev = vlan_dev; + else + if (vlan_id) + goto drop; return (polling ? netif_receive_skb(skb) : netif_rx(skb)); @@ -82,16 +89,22 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp, unsigned int vlan_tci, struct sk_buff *skb) { struct sk_buff *p; + struct net_device *vlan_dev; + u16 vlan_id; if (skb_bond_should_drop(skb, ACCESS_ONCE(skb->dev->master))) skb->deliver_no_wcard = 1; 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); - - if (!skb->dev) - goto drop; + vlan_id = vlan_tci & VLAN_VID_MASK; + vlan_dev = vlan_group_get_device(grp, vlan_id); + + if (vlan_dev) + skb->dev = vlan_dev; + else + if (vlan_id) + goto drop; for (p = napi->gro_list; p; p = p->next) { NAPI_GRO_CB(p)->same_flow = diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c index 5298426..65512c3 100644 --- a/net/8021q/vlan_dev.c +++ b/net/8021q/vlan_dev.c @@ -142,6 +142,7 @@ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev, { struct vlan_hdr *vhdr; struct vlan_rx_stats *rx_stats; + struct net_device *vlan_dev; u16 vlan_id; u16 vlan_tci; @@ -157,8 +158,18 @@ int vlan_skb_recv(struct sk_buff *skb, struct net_device *dev, vlan_id = vlan_tci & VLAN_VID_MASK; rcu_read_lock(); - skb->dev = __find_vlan_dev(dev, vlan_id); - if (!skb->dev) { + vlan_dev = __find_vlan_dev(dev, vlan_id); + + /* If the VLAN device is defined, we use it. + * If not, and the VID is 0, it is a 802.1p packet (not + * really a VLAN), so we will just netif_rx it later to the + * original interface, but with the skb->proto set to the + * wrapped proto: we do nothing here. + */ + + if (vlan_dev) { + skb->dev = vlan_dev; + } else if (vlan_id) { pr_debug("%s: ERROR: No net_device for VID: %u on dev: %s\n", __func__, vlan_id, dev->name); goto err_unlock;