<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/bridge, branch v4.4.13</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>bridge: fix igmp / mld query parsing</title>
<updated>2016-05-19T00:06:42+00:00</updated>
<author>
<name>Linus Lüssing</name>
<email>linus.luessing@c0d3.blue</email>
</author>
<published>2016-05-04T15:25:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5895701216ef9e4f89734433dcf64c85fc3d64a8'/>
<id>5895701216ef9e4f89734433dcf64c85fc3d64a8</id>
<content type='text'>
[ Upstream commit 856ce5d083e14571d051301fe3c65b32b8cbe321 ]

With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.

The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.

If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.

Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich &lt;sw@simonwunderlich.de&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 856ce5d083e14571d051301fe3c65b32b8cbe321 ]

With the newly introduced helper functions the skb pulling is hidden
in the checksumming function - and undone before returning to the
caller.

The IGMP and MLD query parsing functions in the bridge still
assumed that the skb is pointing to the beginning of the IGMP/MLD
message while it is now kept at the beginning of the IPv4/6 header.

If there is a querier somewhere else, then this either causes
the multicast snooping to stay disabled even though it could be
enabled. Or, if we have the querier enabled too, then this can
create unnecessary IGMP / MLD query messages on the link.

Fixing this by taking the offset between IP and IGMP/MLD header into
account, too.

Fixes: 9afd85c9e455 ("net: Export IGMP/MLD message validation code")
Reported-by: Simon Wunderlich &lt;sw@simonwunderlich.de&gt;
Signed-off-by: Linus Lüssing &lt;linus.luessing@c0d3.blue&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: bridge: fix old ioctl unlocked net device walk</title>
<updated>2016-05-19T00:06:42+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@cumulusnetworks.com</email>
</author>
<published>2016-05-04T14:18:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=97c2160da468f71ba998f2c6c82ed33cdfbc7245'/>
<id>97c2160da468f71ba998f2c6c82ed33cdfbc7245</id>
<content type='text'>
[ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [&lt;ffffffff8138dec5&gt;] dump_stack+0x85/0xc0
[  957.423009]  [&lt;ffffffffa05ead32&gt;]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [&lt;ffffffff81515beb&gt;] sock_ioctl+0x22b/0x290
[  957.423009]  [&lt;ffffffff8126ba75&gt;] do_vfs_ioctl+0x95/0x700
[  957.423009]  [&lt;ffffffff8126c159&gt;] SyS_ioctl+0x79/0x90
[  957.423009]  [&lt;ffffffff8163a4c0&gt;] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [&lt;ffffffff8138dec5&gt;] dump_stack+0x85/0xc0
[  957.423009]  [&lt;ffffffffa05ead32&gt;]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [&lt;ffffffff81515beb&gt;] sock_ioctl+0x22b/0x290
[  957.423009]  [&lt;ffffffff8126ba75&gt;] do_vfs_ioctl+0x95/0x700
[  957.423009]  [&lt;ffffffff8126c159&gt;] SyS_ioctl+0x79/0x90
[  957.423009]  [&lt;ffffffff8163a4c0&gt;] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bridge: Allow set bridge ageing time when switchdev disabled</title>
<updated>2016-04-20T06:42:05+00:00</updated>
<author>
<name>Haishuang Yan</name>
<email>yanhaishuang@cmss.chinamobile.com</email>
</author>
<published>2016-03-29T10:48:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=df371b19630cf045e00f1b09a721bb7103266796'/>
<id>df371b19630cf045e00f1b09a721bb7103266796</id>
<content type='text'>
[ Upstream commit 5e263f712691615fb802f06c98d7638c378f5d11 ]

When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
we should ignore this error code and continue to set the ageing time.

Fixes: c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")
Signed-off-by: Haishuang Yan &lt;yanhaishuang@cmss.chinamobile.com&gt;
Acked-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 5e263f712691615fb802f06c98d7638c378f5d11 ]

When NET_SWITCHDEV=n, switchdev_port_attr_set will return -EOPNOTSUPP,
we should ignore this error code and continue to set the ageing time.

Fixes: c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")
Signed-off-by: Haishuang Yan &lt;yanhaishuang@cmss.chinamobile.com&gt;
Acked-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bridge: allow zero ageing time</title>
<updated>2016-04-20T06:42:02+00:00</updated>
<author>
<name>Stephen Hemminger</name>
<email>shemming@brocade.com</email>
</author>
<published>2016-03-08T20:59:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=acbea202fbba11c52df2fd4040c19bb796fd37fa'/>
<id>acbea202fbba11c52df2fd4040c19bb796fd37fa</id>
<content type='text'>
[ Upstream commit 4c656c13b254d598e83e586b7b4d36a2043dad85 ]

This fixes a regression in the bridge ageing time caused by:
commit c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")

There are users of Linux bridge which use the feature that if ageing time
is set to 0 it causes entries to never expire. See:
  https://www.linuxfoundation.org/collaborate/workgroups/networking/bridge

For a pure software bridge, it is unnecessary for the code to have
arbitrary restrictions on what values are allowable.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Acked-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4c656c13b254d598e83e586b7b4d36a2043dad85 ]

This fixes a regression in the bridge ageing time caused by:
commit c62987bbd8a1 ("bridge: push bridge setting ageing_time down to switchdev")

There are users of Linux bridge which use the feature that if ageing time
is set to 0 it causes entries to never expire. See:
  https://www.linuxfoundation.org/collaborate/workgroups/networking/bridge

For a pure software bridge, it is unnecessary for the code to have
arbitrary restrictions on what values are allowable.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Acked-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>switchdev: Require RTNL mutex to be held when sending FDB notifications</title>
<updated>2016-03-03T23:07:04+00:00</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@mellanox.com</email>
</author>
<published>2016-01-27T14:16:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ba50e6d96f3daf3db8396cc3529f90339d9ef59a'/>
<id>ba50e6d96f3daf3db8396cc3529f90339d9ef59a</id>
<content type='text'>
[ Upstream commit 4f2c6ae5c64c353fb1b0425e4747e5603feadba1 ]

When switchdev drivers process FDB notifications from the underlying
device they resolve the netdev to which the entry points to and notify
the bridge using the switchdev notifier.

However, since the RTNL mutex is not held there is nothing preventing
the netdev from disappearing in the middle, which will cause
br_switchdev_event() to dereference a non-existing netdev.

Make switchdev drivers hold the lock at the beginning of the
notification processing session and release it once it ends, after
notifying the bridge.

Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
when RTNL mutex is held.

Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 4f2c6ae5c64c353fb1b0425e4747e5603feadba1 ]

When switchdev drivers process FDB notifications from the underlying
device they resolve the netdev to which the entry points to and notify
the bridge using the switchdev notifier.

However, since the RTNL mutex is not held there is nothing preventing
the netdev from disappearing in the middle, which will cause
br_switchdev_event() to dereference a non-existing netdev.

Make switchdev drivers hold the lock at the beginning of the
notification processing session and release it once it ends, after
notifying the bridge.

Also, remove switchdev_mutex and fdb_lock, as they are no longer needed
when RTNL mutex is held.

Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bridge: fix lockdep addr_list_lock false positive splat</title>
<updated>2016-01-31T19:29:01+00:00</updated>
<author>
<name>Nikolay Aleksandrov</name>
<email>nikolay@cumulusnetworks.com</email>
</author>
<published>2016-01-15T18:03:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db4dca1ade8fedc227ddd32e49d60f99cbcfceee'/>
<id>db4dca1ade8fedc227ddd32e49d60f99cbcfceee</id>
<content type='text'>
[ Upstream commit c6894dec8ea9ae05747124dce98b3b5c2e69b168 ]

After promisc mode management was introduced a bridge device could do
dev_set_promiscuity from its ndo_change_rx_flags() callback which in
turn can be called after the bridge's addr_list_lock has been taken
(e.g. by dev_uc_add). This causes a false positive lockdep splat because
the port interfaces' addr_list_lock is taken when br_manage_promisc()
runs after the bridge's addr list lock was already taken.
To remove the false positive introduce a custom bridge addr_list_lock
class and set it on bridge init.
A simple way to reproduce this is with the following:
$ brctl addbr br0
$ ip l add l br0 br0.100 type vlan id 100
$ ip l set br0 up
$ ip l set br0.100 up
$ echo 1 &gt; /sys/class/net/br0/bridge/vlan_filtering
$ brctl addif br0 eth0
Splat:
[   43.684325] =============================================
[   43.684485] [ INFO: possible recursive locking detected ]
[   43.684636] 4.4.0-rc8+ #54 Not tainted
[   43.684755] ---------------------------------------------
[   43.684906] brctl/1187 is trying to acquire lock:
[   43.685047]  (_xmit_ETHER){+.....}, at: [&lt;ffffffff8150169e&gt;] dev_set_rx_mode+0x1e/0x40
[   43.685460]  but task is already holding lock:
[   43.685618]  (_xmit_ETHER){+.....}, at: [&lt;ffffffff815072a7&gt;] dev_uc_add+0x27/0x80
[   43.686015]  other info that might help us debug this:
[   43.686316]  Possible unsafe locking scenario:

[   43.686743]        CPU0
[   43.686967]        ----
[   43.687197]   lock(_xmit_ETHER);
[   43.687544]   lock(_xmit_ETHER);
[   43.687886] *** DEADLOCK ***

[   43.688438]  May be due to missing lock nesting notation

[   43.688882] 2 locks held by brctl/1187:
[   43.689134]  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff81510317&gt;] rtnl_lock+0x17/0x20
[   43.689852]  #1:  (_xmit_ETHER){+.....}, at: [&lt;ffffffff815072a7&gt;] dev_uc_add+0x27/0x80
[   43.690575] stack backtrace:
[   43.690970] CPU: 0 PID: 1187 Comm: brctl Not tainted 4.4.0-rc8+ #54
[   43.691270] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
[   43.691770]  ffffffff826a25c0 ffff8800369fb8e0 ffffffff81360ceb ffffffff826a25c0
[   43.692425]  ffff8800369fb9b8 ffffffff810d0466 ffff8800369fb968 ffffffff81537139
[   43.693071]  ffff88003a08c880 0000000000000000 00000000ffffffff 0000000002080020
[   43.693709] Call Trace:
[   43.693931]  [&lt;ffffffff81360ceb&gt;] dump_stack+0x4b/0x70
[   43.694199]  [&lt;ffffffff810d0466&gt;] __lock_acquire+0x1e46/0x1e90
[   43.694483]  [&lt;ffffffff81537139&gt;] ? netlink_broadcast_filtered+0x139/0x3e0
[   43.694789]  [&lt;ffffffff8153b5da&gt;] ? nlmsg_notify+0x5a/0xc0
[   43.695064]  [&lt;ffffffff810d10f5&gt;] lock_acquire+0xe5/0x1f0
[   43.695340]  [&lt;ffffffff8150169e&gt;] ? dev_set_rx_mode+0x1e/0x40
[   43.695623]  [&lt;ffffffff815edea5&gt;] _raw_spin_lock_bh+0x45/0x80
[   43.695901]  [&lt;ffffffff8150169e&gt;] ? dev_set_rx_mode+0x1e/0x40
[   43.696180]  [&lt;ffffffff8150169e&gt;] dev_set_rx_mode+0x1e/0x40
[   43.696460]  [&lt;ffffffff8150189c&gt;] dev_set_promiscuity+0x3c/0x50
[   43.696750]  [&lt;ffffffffa0586845&gt;] br_port_set_promisc+0x25/0x50 [bridge]
[   43.697052]  [&lt;ffffffffa05869aa&gt;] br_manage_promisc+0x8a/0xe0 [bridge]
[   43.697348]  [&lt;ffffffffa05826ee&gt;] br_dev_change_rx_flags+0x1e/0x20 [bridge]
[   43.697655]  [&lt;ffffffff81501532&gt;] __dev_set_promiscuity+0x132/0x1f0
[   43.697943]  [&lt;ffffffff81501672&gt;] __dev_set_rx_mode+0x82/0x90
[   43.698223]  [&lt;ffffffff815072de&gt;] dev_uc_add+0x5e/0x80
[   43.698498]  [&lt;ffffffffa05b3c62&gt;] vlan_device_event+0x542/0x650 [8021q]
[   43.698798]  [&lt;ffffffff8109886d&gt;] notifier_call_chain+0x5d/0x80
[   43.699083]  [&lt;ffffffff810988b6&gt;] raw_notifier_call_chain+0x16/0x20
[   43.699374]  [&lt;ffffffff814f456e&gt;] call_netdevice_notifiers_info+0x6e/0x80
[   43.699678]  [&lt;ffffffff814f4596&gt;] call_netdevice_notifiers+0x16/0x20
[   43.699973]  [&lt;ffffffffa05872be&gt;] br_add_if+0x47e/0x4c0 [bridge]
[   43.700259]  [&lt;ffffffffa058801e&gt;] add_del_if+0x6e/0x80 [bridge]
[   43.700548]  [&lt;ffffffffa0588b5f&gt;] br_dev_ioctl+0xaf/0xc0 [bridge]
[   43.700836]  [&lt;ffffffff8151a7ac&gt;] dev_ifsioc+0x30c/0x3c0
[   43.701106]  [&lt;ffffffff8151aac9&gt;] dev_ioctl+0xf9/0x6f0
[   43.701379]  [&lt;ffffffff81254345&gt;] ? mntput_no_expire+0x5/0x450
[   43.701665]  [&lt;ffffffff812543ee&gt;] ? mntput_no_expire+0xae/0x450
[   43.701947]  [&lt;ffffffff814d7b02&gt;] sock_do_ioctl+0x42/0x50
[   43.702219]  [&lt;ffffffff814d8175&gt;] sock_ioctl+0x1e5/0x290
[   43.702500]  [&lt;ffffffff81242d0b&gt;] do_vfs_ioctl+0x2cb/0x5c0
[   43.702771]  [&lt;ffffffff81243079&gt;] SyS_ioctl+0x79/0x90
[   43.703033]  [&lt;ffffffff815eebb6&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a

CC: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
CC: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
CC: Bridge list &lt;bridge@lists.linux-foundation.org&gt;
CC: Andy Gospodarek &lt;gospo@cumulusnetworks.com&gt;
CC: Roopa Prabhu &lt;roopa@cumulusnetworks.com&gt;
Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
Reported-by: Andy Gospodarek &lt;gospo@cumulusnetworks.com&gt;
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit c6894dec8ea9ae05747124dce98b3b5c2e69b168 ]

After promisc mode management was introduced a bridge device could do
dev_set_promiscuity from its ndo_change_rx_flags() callback which in
turn can be called after the bridge's addr_list_lock has been taken
(e.g. by dev_uc_add). This causes a false positive lockdep splat because
the port interfaces' addr_list_lock is taken when br_manage_promisc()
runs after the bridge's addr list lock was already taken.
To remove the false positive introduce a custom bridge addr_list_lock
class and set it on bridge init.
A simple way to reproduce this is with the following:
$ brctl addbr br0
$ ip l add l br0 br0.100 type vlan id 100
$ ip l set br0 up
$ ip l set br0.100 up
$ echo 1 &gt; /sys/class/net/br0/bridge/vlan_filtering
$ brctl addif br0 eth0
Splat:
[   43.684325] =============================================
[   43.684485] [ INFO: possible recursive locking detected ]
[   43.684636] 4.4.0-rc8+ #54 Not tainted
[   43.684755] ---------------------------------------------
[   43.684906] brctl/1187 is trying to acquire lock:
[   43.685047]  (_xmit_ETHER){+.....}, at: [&lt;ffffffff8150169e&gt;] dev_set_rx_mode+0x1e/0x40
[   43.685460]  but task is already holding lock:
[   43.685618]  (_xmit_ETHER){+.....}, at: [&lt;ffffffff815072a7&gt;] dev_uc_add+0x27/0x80
[   43.686015]  other info that might help us debug this:
[   43.686316]  Possible unsafe locking scenario:

[   43.686743]        CPU0
[   43.686967]        ----
[   43.687197]   lock(_xmit_ETHER);
[   43.687544]   lock(_xmit_ETHER);
[   43.687886] *** DEADLOCK ***

[   43.688438]  May be due to missing lock nesting notation

[   43.688882] 2 locks held by brctl/1187:
[   43.689134]  #0:  (rtnl_mutex){+.+.+.}, at: [&lt;ffffffff81510317&gt;] rtnl_lock+0x17/0x20
[   43.689852]  #1:  (_xmit_ETHER){+.....}, at: [&lt;ffffffff815072a7&gt;] dev_uc_add+0x27/0x80
[   43.690575] stack backtrace:
[   43.690970] CPU: 0 PID: 1187 Comm: brctl Not tainted 4.4.0-rc8+ #54
[   43.691270] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
[   43.691770]  ffffffff826a25c0 ffff8800369fb8e0 ffffffff81360ceb ffffffff826a25c0
[   43.692425]  ffff8800369fb9b8 ffffffff810d0466 ffff8800369fb968 ffffffff81537139
[   43.693071]  ffff88003a08c880 0000000000000000 00000000ffffffff 0000000002080020
[   43.693709] Call Trace:
[   43.693931]  [&lt;ffffffff81360ceb&gt;] dump_stack+0x4b/0x70
[   43.694199]  [&lt;ffffffff810d0466&gt;] __lock_acquire+0x1e46/0x1e90
[   43.694483]  [&lt;ffffffff81537139&gt;] ? netlink_broadcast_filtered+0x139/0x3e0
[   43.694789]  [&lt;ffffffff8153b5da&gt;] ? nlmsg_notify+0x5a/0xc0
[   43.695064]  [&lt;ffffffff810d10f5&gt;] lock_acquire+0xe5/0x1f0
[   43.695340]  [&lt;ffffffff8150169e&gt;] ? dev_set_rx_mode+0x1e/0x40
[   43.695623]  [&lt;ffffffff815edea5&gt;] _raw_spin_lock_bh+0x45/0x80
[   43.695901]  [&lt;ffffffff8150169e&gt;] ? dev_set_rx_mode+0x1e/0x40
[   43.696180]  [&lt;ffffffff8150169e&gt;] dev_set_rx_mode+0x1e/0x40
[   43.696460]  [&lt;ffffffff8150189c&gt;] dev_set_promiscuity+0x3c/0x50
[   43.696750]  [&lt;ffffffffa0586845&gt;] br_port_set_promisc+0x25/0x50 [bridge]
[   43.697052]  [&lt;ffffffffa05869aa&gt;] br_manage_promisc+0x8a/0xe0 [bridge]
[   43.697348]  [&lt;ffffffffa05826ee&gt;] br_dev_change_rx_flags+0x1e/0x20 [bridge]
[   43.697655]  [&lt;ffffffff81501532&gt;] __dev_set_promiscuity+0x132/0x1f0
[   43.697943]  [&lt;ffffffff81501672&gt;] __dev_set_rx_mode+0x82/0x90
[   43.698223]  [&lt;ffffffff815072de&gt;] dev_uc_add+0x5e/0x80
[   43.698498]  [&lt;ffffffffa05b3c62&gt;] vlan_device_event+0x542/0x650 [8021q]
[   43.698798]  [&lt;ffffffff8109886d&gt;] notifier_call_chain+0x5d/0x80
[   43.699083]  [&lt;ffffffff810988b6&gt;] raw_notifier_call_chain+0x16/0x20
[   43.699374]  [&lt;ffffffff814f456e&gt;] call_netdevice_notifiers_info+0x6e/0x80
[   43.699678]  [&lt;ffffffff814f4596&gt;] call_netdevice_notifiers+0x16/0x20
[   43.699973]  [&lt;ffffffffa05872be&gt;] br_add_if+0x47e/0x4c0 [bridge]
[   43.700259]  [&lt;ffffffffa058801e&gt;] add_del_if+0x6e/0x80 [bridge]
[   43.700548]  [&lt;ffffffffa0588b5f&gt;] br_dev_ioctl+0xaf/0xc0 [bridge]
[   43.700836]  [&lt;ffffffff8151a7ac&gt;] dev_ifsioc+0x30c/0x3c0
[   43.701106]  [&lt;ffffffff8151aac9&gt;] dev_ioctl+0xf9/0x6f0
[   43.701379]  [&lt;ffffffff81254345&gt;] ? mntput_no_expire+0x5/0x450
[   43.701665]  [&lt;ffffffff812543ee&gt;] ? mntput_no_expire+0xae/0x450
[   43.701947]  [&lt;ffffffff814d7b02&gt;] sock_do_ioctl+0x42/0x50
[   43.702219]  [&lt;ffffffff814d8175&gt;] sock_ioctl+0x1e5/0x290
[   43.702500]  [&lt;ffffffff81242d0b&gt;] do_vfs_ioctl+0x2cb/0x5c0
[   43.702771]  [&lt;ffffffff81243079&gt;] SyS_ioctl+0x79/0x90
[   43.703033]  [&lt;ffffffff815eebb6&gt;] entry_SYSCALL_64_fastpath+0x16/0x7a

CC: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
CC: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
CC: Bridge list &lt;bridge@lists.linux-foundation.org&gt;
CC: Andy Gospodarek &lt;gospo@cumulusnetworks.com&gt;
CC: Roopa Prabhu &lt;roopa@cumulusnetworks.com&gt;
Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
Reported-by: Andy Gospodarek &lt;gospo@cumulusnetworks.com&gt;
Signed-off-by: Nikolay Aleksandrov &lt;nikolay@cumulusnetworks.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bridge: Only call /sbin/bridge-stp for the initial network namespace</title>
<updated>2016-01-05T21:46:17+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2016-01-05T09:46:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff62198553e43cdffa9d539f6165d3e83f8a42bc'/>
<id>ff62198553e43cdffa9d539f6165d3e83f8a42bc</id>
<content type='text'>
[I stole this patch from Eric Biederman. He wrote:]

&gt; There is no defined mechanism to pass network namespace information
&gt; into /sbin/bridge-stp therefore don't even try to invoke it except
&gt; for bridge devices in the initial network namespace.
&gt;
&gt; It is possible for unprivileged users to cause /sbin/bridge-stp to be
&gt; invoked for any network device name which if /sbin/bridge-stp does not
&gt; guard against unreasonable arguments or being invoked twice on the
&gt; same network device could cause problems.

[Hannes: changed patch using netns_eq]

Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[I stole this patch from Eric Biederman. He wrote:]

&gt; There is no defined mechanism to pass network namespace information
&gt; into /sbin/bridge-stp therefore don't even try to invoke it except
&gt; for bridge devices in the initial network namespace.
&gt;
&gt; It is possible for unprivileged users to cause /sbin/bridge-stp to be
&gt; invoked for any network device name which if /sbin/bridge-stp does not
&gt; guard against unreasonable arguments or being invoked twice on the
&gt; same network device could cause problems.

[Hannes: changed patch using netns_eq]

Cc: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Eric W. Biederman &lt;ebiederm@xmission.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>switchdev: bridge: Pass ageing time as clock_t instead of jiffies</title>
<updated>2015-12-22T20:56:44+00:00</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@mellanox.com</email>
</author>
<published>2015-12-21T08:56:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ef9cdd0fed3875b1ae9cc85987d8143354b2d4c8'/>
<id>ef9cdd0fed3875b1ae9cc85987d8143354b2d4c8</id>
<content type='text'>
The bridge's ageing time is offloaded to hardware when:
	1) A port joins a bridge
	2) The ageing time of the bridge is changed

In the first case the ageing time is offloaded as jiffies, but in the
second case it's offloaded as clock_t, which is what existing switchdev
drivers expect to receive.

Fixes: 6ac311ae8bfb ("Adding switchdev ageing notification on port bridged")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bridge's ageing time is offloaded to hardware when:
	1) A port joins a bridge
	2) The ageing time of the bridge is changed

In the first case the ageing time is offloaded as jiffies, but in the
second case it's offloaded as clock_t, which is what existing switchdev
drivers expect to receive.

Fixes: 6ac311ae8bfb ("Adding switchdev ageing notification on port bridged")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>switchdev: bridge: Check return code is not EOPNOTSUPP</title>
<updated>2015-11-16T19:56:03+00:00</updated>
<author>
<name>Ido Schimmel</name>
<email>idosch@mellanox.com</email>
</author>
<published>2015-11-13T11:06:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bbe14f54297467ddb23b7d1db564a2468c6ae151'/>
<id>bbe14f54297467ddb23b7d1db564a2468c6ae151</id>
<content type='text'>
When NET_SWITCHDEV=n, switchdev_port_attr_set simply returns EOPNOTSUPP.
In this case we should not emit errors and warnings to the kernel log.

Reported-by: Sander Eikelenboom &lt;linux@eikelenboom.it&gt;
Tested-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Fixes: 0bc05d585d38 ("switchdev: allow caller to explicitly request
attr_set as deferred")
Fixes: 6ac311ae8bfb ("Adding switchdev ageing notification on port
bridged")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When NET_SWITCHDEV=n, switchdev_port_attr_set simply returns EOPNOTSUPP.
In this case we should not emit errors and warnings to the kernel log.

Reported-by: Sander Eikelenboom &lt;linux@eikelenboom.it&gt;
Tested-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Fixes: 0bc05d585d38 ("switchdev: allow caller to explicitly request
attr_set as deferred")
Fixes: 6ac311ae8bfb ("Adding switchdev ageing notification on port
bridged")
Signed-off-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Signed-off-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "bridge: Allow forward delay to be cfgd when STP enabled"</title>
<updated>2015-11-10T20:41:36+00:00</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevich@gmail.com</email>
</author>
<published>2015-11-10T11:15:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8a921265e2cd31e61a0c2eda582af54c5bfef897'/>
<id>8a921265e2cd31e61a0c2eda582af54c5bfef897</id>
<content type='text'>
This reverts commit 34c2d9fb0498c066afbe610b15e18995fd8be792.

There are 2 reasons for this revert:
 1)  The commit in question doesn't do what it says it does.  The
     description reads: "Allow bridge forward delay to be configured
     when Spanning Tree is enabled."  This was already the case before
     the commit was made.  What the commit actually do was disallow
     invalid values or 'forward_delay' when STP was turned off.

 2)  The above change was actually a change in the user observed
     behavior and broke things like libvirt and other network configs
     that set 'forward_delay' to 0 without enabling STP.  The value
     of 0 is actually used when STP is turned off to immediately mark
     the bridge as forwarding.

Signed-off-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 34c2d9fb0498c066afbe610b15e18995fd8be792.

There are 2 reasons for this revert:
 1)  The commit in question doesn't do what it says it does.  The
     description reads: "Allow bridge forward delay to be configured
     when Spanning Tree is enabled."  This was already the case before
     the commit was made.  What the commit actually do was disallow
     invalid values or 'forward_delay' when STP was turned off.

 2)  The above change was actually a change in the user observed
     behavior and broke things like libvirt and other network configs
     that set 'forward_delay' to 0 without enabling STP.  The value
     of 0 is actually used when STP is turned off to immediately mark
     the bridge as forwarding.

Signed-off-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
