2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Simon Arlott]

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

If I remove eth0 from the bridge, eth0.3840 starts working again. It
still works if eth0.3840 is part of a bridge but eth0 isn't (the device
is in promiscuous mode). I've only tested with broadcast traffic.

This works with 2.6.36.

git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
first bad commit.

The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
use).

-- 
Simon Arlott

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Ben Hutchings]

On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
> 
> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
> to receive packets. Using tcpdump on eth0 shows the packets being
> received with a VLAN tag but they don't appear on eth0.3840. They appear
> with the VLAN tag on the bridge interface.
[...]

This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled.  (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
would consider this an improvement.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Simon Arlott]

On 17/01/11 16:00, Ben Hutchings wrote:
> On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
>> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
>> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
>> 
>> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
>> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
>> to receive packets. Using tcpdump on eth0 shows the packets being
>> received with a VLAN tag but they don't appear on eth0.3840. They appear
>> with the VLAN tag on the bridge interface.
> [...]
> 
> This means the behaviour is now consistent, whether or not hardware VLAN
> tag stripping is enabled.  (I previously pointed out the inconsistent
> behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
> would consider this an improvement.

Shouldn't the kernel also prevent a device from being both part of a
bridge and having VLANs? Instead everything appears to work except
incoming traffic.

-- 
Simon Arlott

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Mon, Jan 17, 2011 at 10:17 AM, Simon Arlott <simon@fire.lp0.eu> wrote:
> On 17/01/11 16:00, Ben Hutchings wrote:
>> On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:
>>> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
>>> [    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
>>>
>>> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
>>> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
>>> to receive packets. Using tcpdump on eth0 shows the packets being
>>> received with a VLAN tag but they don't appear on eth0.3840. They appear
>>> with the VLAN tag on the bridge interface.
>> [...]
>>
>> This means the behaviour is now consistent, whether or not hardware VLAN
>> tag stripping is enabled.  (I previously pointed out the inconsistent
>> behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
>> would consider this an improvement.
>
> Shouldn't the kernel also prevent a device from being both part of a
> bridge and having VLANs? Instead everything appears to work except
> incoming traffic.

It might make sense, although you have similar effects with non-vlan
traffic to the device as well.  You could make the same argument that
we shouldn't allow IP addresses, etc. to be assigned to bridged
devices.  There are also other components that use the bridge hooks
that would need to be checked.  All this starts to get a bit messy.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Maciej Rutecki]

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there, thanks!

On niedziela, 16 stycznia 2011 o 15:09:32 Simon Arlott wrote:
> [    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16,
> addr 00:e0:81:4d:2b:ec [    1.666767] forcedeth 0000:00:08.0: highdma csum
> vlan pwrctl mgmt gbit lnktim msi desc-v3
> 
> I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
> While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
> to receive packets. Using tcpdump on eth0 shows the packets being
> received with a VLAN tag but they don't appear on eth0.3840. They appear
> with the VLAN tag on the bridge interface.
> 
> If I remove eth0 from the bridge, eth0.3840 starts working again. It
> still works if eth0.3840 is part of a bridge but eth0 isn't (the device
> is in promiscuous mode). I've only tested with broadcast traffic.
> 
> This works with 2.6.36.
> 
> git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
> first bad commit.
> 
> The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
> ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
> likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
> use).

-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Jesse Gross]

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
<maciej.rutecki@gmail.com> wrote:
> I created a Bugzilla entry at
> https://bugzilla.kernel.org/show_bug.cgi?id=27432
> for your bug report, please add your address to the CC list in there, thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[Maciej Rutecki]

On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:
> On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
> 
> <maciej.rutecki@gmail.com> wrote:
> > I created a Bugzilla entry at
> > https://bugzilla.kernel.org/show_bug.cgi?id=27432
> > for your bug report, please add your address to the CC list in there,
> > thanks!
> 
> This isn't a bug - the change resolved behavior that varied depending
> on what NIC was in use.

Thanks for the update. Closing.

Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl