<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/net/bonding, branch v3.7</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>bonding: fix race condition in bonding_store_slaves_active</title>
<updated>2012-11-29T18:13:15+00:00</updated>
<author>
<name>nikolay@redhat.com</name>
<email>nikolay@redhat.com</email>
</author>
<published>2012-11-29T01:37:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e196c0e579902f42cf72414461fb034e5a1ffbf7'/>
<id>e196c0e579902f42cf72414461fb034e5a1ffbf7</id>
<content type='text'>
Race between bonding_store_slaves_active() and slave manipulation
 functions. The bond_for_each_slave use in bonding_store_slaves_active()
 is not protected by any synchronization mechanism.
 NULL pointer dereference is easy to reach.
 Fixed by acquiring the bond-&gt;lock for the slave walk.

 v2: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.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>
Race between bonding_store_slaves_active() and slave manipulation
 functions. The bond_for_each_slave use in bonding_store_slaves_active()
 is not protected by any synchronization mechanism.
 NULL pointer dereference is easy to reach.
 Fixed by acquiring the bond-&gt;lock for the slave walk.

 v2: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: make arp_ip_target parameter checks consistent with sysfs</title>
<updated>2012-11-29T18:13:15+00:00</updated>
<author>
<name>nikolay@redhat.com</name>
<email>nikolay@redhat.com</email>
</author>
<published>2012-11-29T01:34:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=90fb6250c509cabd425b7ae4524053dba2e27e2c'/>
<id>90fb6250c509cabd425b7ae4524053dba2e27e2c</id>
<content type='text'>
The module can be loaded with arp_ip_target="255.255.255.255" which makes
 it impossible to remove as the function in sysfs checks for that value,
 so we make the parameter checks consistent with sysfs.

 v2: Fix formatting
 v3: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.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 module can be loaded with arp_ip_target="255.255.255.255" which makes
 it impossible to remove as the function in sysfs checks for that value,
 so we make the parameter checks consistent with sysfs.

 v2: Fix formatting
 v3: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: fix miimon and arp_interval delayed work race conditions</title>
<updated>2012-11-29T18:13:15+00:00</updated>
<author>
<name>nikolay@redhat.com</name>
<email>nikolay@redhat.com</email>
</author>
<published>2012-11-29T01:31:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fbb0c41b814d497c656fc7be9e35456f139cb2fb'/>
<id>fbb0c41b814d497c656fc7be9e35456f139cb2fb</id>
<content type='text'>
First I would give three observations which will be used later.
Observation 1: if (delayed_work_pending(wq)) cancel_delayed_work(wq)
 This usage is wrong because the pending bit is cleared just before the
 work's fn is executed and if the function re-arms itself we might end up
 with the work still running. It's safe to call cancel_delayed_work_sync()
 even if the work is not queued at all.
Observation 2: Use of INIT_DELAYED_WORK()
 Work needs to be initialized only once prior to (de/en)queueing.
Observation 3: IFF_UP is set only after ndo_open is called

Related race conditions:
1. Race between bonding_store_miimon() and bonding_store_arp_interval()
 Because of Obs.1 we can end up having both works enqueued.
2. Multiple races with INIT_DELAYED_WORK()
 Since the works are not protected by anything between INIT_DELAYED_WORK()
 and calls to (en/de)queue it is possible for races between the following
 functions:
 (races are also possible between the calls to INIT_DELAYED_WORK()
  and workqueue code)
 bonding_store_miimon() - bonding_store_arp_interval(), bond_close(),
			  bond_open(), enqueued functions
 bonding_store_arp_interval() - bonding_store_miimon(), bond_close(),
				bond_open(), enqueued functions
3. By Obs.1 we need to change bond_cancel_all()

Bugs 1 and 2 are fixed by moving all work initializations in bond_open
which by Obs. 2 and Obs. 3 and the fact that we make sure that all works
are cancelled in bond_close(), is guaranteed not to have any work
enqueued.
Also RTNL lock is now acquired in bonding_store_miimon/arp_interval so
they can't race with bond_close and bond_open. The opposing work is
cancelled only if the IFF_UP flag is set and it is cancelled
unconditionally. The opposing work is already cancelled if the interface
is down so no need to cancel it again. This way we don't need new
synchronizations for the bonding workqueue. These bugs (and fixes) are
tied together and belong in the same patch.
Note: I have left 1 line intentionally over 80 characters (84) because I
      didn't like how it looks broken down. If you'd prefer it otherwise,
      then simply break it.

 v2: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.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>
First I would give three observations which will be used later.
Observation 1: if (delayed_work_pending(wq)) cancel_delayed_work(wq)
 This usage is wrong because the pending bit is cleared just before the
 work's fn is executed and if the function re-arms itself we might end up
 with the work still running. It's safe to call cancel_delayed_work_sync()
 even if the work is not queued at all.
Observation 2: Use of INIT_DELAYED_WORK()
 Work needs to be initialized only once prior to (de/en)queueing.
Observation 3: IFF_UP is set only after ndo_open is called

Related race conditions:
1. Race between bonding_store_miimon() and bonding_store_arp_interval()
 Because of Obs.1 we can end up having both works enqueued.
2. Multiple races with INIT_DELAYED_WORK()
 Since the works are not protected by anything between INIT_DELAYED_WORK()
 and calls to (en/de)queue it is possible for races between the following
 functions:
 (races are also possible between the calls to INIT_DELAYED_WORK()
  and workqueue code)
 bonding_store_miimon() - bonding_store_arp_interval(), bond_close(),
			  bond_open(), enqueued functions
 bonding_store_arp_interval() - bonding_store_miimon(), bond_close(),
				bond_open(), enqueued functions
3. By Obs.1 we need to change bond_cancel_all()

Bugs 1 and 2 are fixed by moving all work initializations in bond_open
which by Obs. 2 and Obs. 3 and the fact that we make sure that all works
are cancelled in bond_close(), is guaranteed not to have any work
enqueued.
Also RTNL lock is now acquired in bonding_store_miimon/arp_interval so
they can't race with bond_close and bond_open. The opposing work is
cancelled only if the IFF_UP flag is set and it is cancelled
unconditionally. The opposing work is already cancelled if the interface
is down so no need to cancel it again. This way we don't need new
synchronizations for the bonding workqueue. These bugs (and fixes) are
tied together and belong in the same patch.
Note: I have left 1 line intentionally over 80 characters (84) because I
      didn't like how it looks broken down. If you'd prefer it otherwise,
      then simply break it.

 v2: Make description text &lt; 75 columns

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.</title>
<updated>2012-11-21T16:50:31+00:00</updated>
<author>
<name>Sarveshwar Bandi</name>
<email>sarveshwar.bandi@emulex.com</email>
</author>
<published>2012-11-21T04:35:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0e376bd0b791ac6ac6bdb051492df0769c840848'/>
<id>0e376bd0b791ac6ac6bdb051492df0769c840848</id>
<content type='text'>
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices during enslave and detach.

Signed-off-by: Sarveshwar Bandi &lt;sarveshwar.bandi@emulex.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.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>
Patch sets the lowest gso_max_size and gso_max_segs values of the slave devices during enslave and detach.

Signed-off-by: Sarveshwar Bandi &lt;sarveshwar.bandi@emulex.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: fix second off-by-one error</title>
<updated>2012-11-01T15:53:44+00:00</updated>
<author>
<name>nikolay@redhat.com</name>
<email>nikolay@redhat.com</email>
</author>
<published>2012-10-31T06:03:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c84e1590d149cfc885062e938944941f33e69f38'/>
<id>c84e1590d149cfc885062e938944941f33e69f38</id>
<content type='text'>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.

How to reproduce:
 with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
 modprobe bonding; echo 1 &gt; /sys/class/net/bond0/bonding/mode;
 echo "AAAAAAAAAAAAAAAA" &gt; /sys/class/net/bond0/bonding/active_slave;

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;

Note: Sorry for the second patch but I missed this one while checking
      the file. You can squash them into one patch.
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.

How to reproduce:
 with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
 modprobe bonding; echo 1 &gt; /sys/class/net/bond0/bonding/mode;
 echo "AAAAAAAAAAAAAAAA" &gt; /sys/class/net/bond0/bonding/active_slave;

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;

Note: Sorry for the second patch but I missed this one while checking
      the file. You can squash them into one patch.
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: fix off-by-one error</title>
<updated>2012-11-01T15:53:43+00:00</updated>
<author>
<name>nikolay@redhat.com</name>
<email>nikolay@redhat.com</email>
</author>
<published>2012-10-31T04:42:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=eb6e98a1b25fb0f347fece9814257a9e1cb537c8'/>
<id>eb6e98a1b25fb0f347fece9814257a9e1cb537c8</id>
<content type='text'>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.

How to reproduce:
 with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
 modprobe bonding; echo 1 &gt; /sys/class/net/bond0/bonding/mode;
 echo "AAAAAAAAAAAAAAAA" &gt; /sys/class/net/bond0/bonding/primary;

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@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>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.

How to reproduce:
 with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
 modprobe bonding; echo 1 &gt; /sys/class/net/bond0/bonding/mode;
 echo "AAAAAAAAAAAAAAAA" &gt; /sys/class/net/bond0/bonding/primary;

Signed-off-by: Nikolay Aleksandrov &lt;nikolay@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vlan: fix bond/team enslave of vlan challenged slave/port</title>
<updated>2012-10-16T18:41:46+00:00</updated>
<author>
<name>Jiri Pirko</name>
<email>jiri@resnulli.us</email>
</author>
<published>2012-10-14T04:30:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=55462cf30ad9768fff6a6d36db21879146a39bdf'/>
<id>55462cf30ad9768fff6a6d36db21879146a39bdf</id>
<content type='text'>
In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.

Reported-by: Jon Stanley &lt;jstanley@rmrf.net&gt;
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&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>
In vlan_uses_dev() check for number of vlan devs rather than existence
of vlan_info. The reason is that vlan id 0 is there without appropriate
vlan dev on it by default which prevented from enslaving vlan challenged
dev.

Reported-by: Jon Stanley &lt;jstanley@rmrf.net&gt;
Signed-off-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: set qdisc_tx_busylock to avoid LOCKDEP splat</title>
<updated>2012-10-04T19:53:48+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2012-10-03T23:05:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=49ee49202b4ac4be95d05e4bf24a9ac8b54c5528'/>
<id>49ee49202b4ac4be95d05e4bf24a9ac8b54c5528</id>
<content type='text'>
If a qdisc is installed on a bonding device, its possible to get
following lockdep splat under stress :

 =============================================
 [ INFO: possible recursive locking detected ]
 3.6.0+ #211 Not tainted
 ---------------------------------------------
 ping/4876 is trying to acquire lock:
  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830

 but task is already holding lock:
  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock);
   lock(dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 6 locks held by ping/4876:
  #0:  (sk_lock-AF_INET){+.+.+.}, at: [&lt;ffffffff815e5030&gt;] raw_sendmsg+0x600/0xc30
  #1:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff815ba4bd&gt;] ip_finish_output+0x12d/0x870
  #2:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff8157a0b0&gt;] dev_queue_xmit+0x0/0x830
  #3:  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830
  #4:  (&amp;bond-&gt;lock){++.?..}, at: [&lt;ffffffffa02128c1&gt;] bond_start_xmit+0x31/0x4b0 [bonding]
  #5:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff8157a0b0&gt;] dev_queue_xmit+0x0/0x830

 stack backtrace:
 Pid: 4876, comm: ping Not tainted 3.6.0+ #211
 Call Trace:
  [&lt;ffffffff810a0145&gt;] __lock_acquire+0x715/0x1b80
  [&lt;ffffffff810a256b&gt;] ? mark_held_locks+0x9b/0x100
  [&lt;ffffffff810a1bf2&gt;] lock_acquire+0x92/0x1d0
  [&lt;ffffffff8157a191&gt;] ? dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff81726b7c&gt;] _raw_spin_lock+0x3c/0x50
  [&lt;ffffffff8157a191&gt;] ? dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff8106264d&gt;] ? rcu_read_lock_bh_held+0x5d/0x90
  [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff8157a0b0&gt;] ? netdev_pick_tx+0x570/0x570
  [&lt;ffffffffa0212a6a&gt;] bond_start_xmit+0x1da/0x4b0 [bonding]
  [&lt;ffffffff815796d0&gt;] dev_hard_start_xmit+0x240/0x6b0
  [&lt;ffffffff81597c6e&gt;] sch_direct_xmit+0xfe/0x2a0
  [&lt;ffffffff8157a249&gt;] dev_queue_xmit+0x199/0x830
  [&lt;ffffffff8157a0b0&gt;] ? netdev_pick_tx+0x570/0x570
  [&lt;ffffffff815ba96f&gt;] ip_finish_output+0x5df/0x870
  [&lt;ffffffff815ba4bd&gt;] ? ip_finish_output+0x12d/0x870
  [&lt;ffffffff815bb964&gt;] ip_output+0x54/0xf0
  [&lt;ffffffff815bad48&gt;] ip_local_out+0x28/0x90
  [&lt;ffffffff815bc444&gt;] ip_send_skb+0x14/0x50
  [&lt;ffffffff815bc4b2&gt;] ip_push_pending_frames+0x32/0x40
  [&lt;ffffffff815e536a&gt;] raw_sendmsg+0x93a/0xc30
  [&lt;ffffffff8128d570&gt;] ? selinux_file_send_sigiotask+0x1f0/0x1f0
  [&lt;ffffffff8109ddb4&gt;] ? __lock_is_held+0x54/0x80
  [&lt;ffffffff815f6730&gt;] ? inet_recvmsg+0x220/0x220
  [&lt;ffffffff8109ddb4&gt;] ? __lock_is_held+0x54/0x80
  [&lt;ffffffff815f6855&gt;] inet_sendmsg+0x125/0x240
  [&lt;ffffffff815f6730&gt;] ? inet_recvmsg+0x220/0x220
  [&lt;ffffffff8155cddb&gt;] sock_sendmsg+0xab/0xe0
  [&lt;ffffffff810a1650&gt;] ? lock_release_non_nested+0xa0/0x2e0
  [&lt;ffffffff810a1650&gt;] ? lock_release_non_nested+0xa0/0x2e0
  [&lt;ffffffff8155d18c&gt;] __sys_sendmsg+0x37c/0x390
  [&lt;ffffffff81195b2a&gt;] ? fsnotify+0x2ca/0x7e0
  [&lt;ffffffff811958e8&gt;] ? fsnotify+0x88/0x7e0
  [&lt;ffffffff81361f36&gt;] ? put_ldisc+0x56/0xd0
  [&lt;ffffffff8116f98a&gt;] ? fget_light+0x3da/0x510
  [&lt;ffffffff8155f6c4&gt;] sys_sendmsg+0x44/0x80
  [&lt;ffffffff8172fc22&gt;] system_call_fastpath+0x16/0x1b

Avoid this problem using a distinct lock_class_key for bonding
devices.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Cc: Andy Gospodarek &lt;andy@greyhouse.net&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>
If a qdisc is installed on a bonding device, its possible to get
following lockdep splat under stress :

 =============================================
 [ INFO: possible recursive locking detected ]
 3.6.0+ #211 Not tainted
 ---------------------------------------------
 ping/4876 is trying to acquire lock:
  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830

 but task is already holding lock:
  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830

 other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock);
   lock(dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 6 locks held by ping/4876:
  #0:  (sk_lock-AF_INET){+.+.+.}, at: [&lt;ffffffff815e5030&gt;] raw_sendmsg+0x600/0xc30
  #1:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff815ba4bd&gt;] ip_finish_output+0x12d/0x870
  #2:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff8157a0b0&gt;] dev_queue_xmit+0x0/0x830
  #3:  (dev-&gt;qdisc_tx_busylock ?: &amp;qdisc_tx_busylock){+.-...}, at: [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830
  #4:  (&amp;bond-&gt;lock){++.?..}, at: [&lt;ffffffffa02128c1&gt;] bond_start_xmit+0x31/0x4b0 [bonding]
  #5:  (rcu_read_lock_bh){.+....}, at: [&lt;ffffffff8157a0b0&gt;] dev_queue_xmit+0x0/0x830

 stack backtrace:
 Pid: 4876, comm: ping Not tainted 3.6.0+ #211
 Call Trace:
  [&lt;ffffffff810a0145&gt;] __lock_acquire+0x715/0x1b80
  [&lt;ffffffff810a256b&gt;] ? mark_held_locks+0x9b/0x100
  [&lt;ffffffff810a1bf2&gt;] lock_acquire+0x92/0x1d0
  [&lt;ffffffff8157a191&gt;] ? dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff81726b7c&gt;] _raw_spin_lock+0x3c/0x50
  [&lt;ffffffff8157a191&gt;] ? dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff8106264d&gt;] ? rcu_read_lock_bh_held+0x5d/0x90
  [&lt;ffffffff8157a191&gt;] dev_queue_xmit+0xe1/0x830
  [&lt;ffffffff8157a0b0&gt;] ? netdev_pick_tx+0x570/0x570
  [&lt;ffffffffa0212a6a&gt;] bond_start_xmit+0x1da/0x4b0 [bonding]
  [&lt;ffffffff815796d0&gt;] dev_hard_start_xmit+0x240/0x6b0
  [&lt;ffffffff81597c6e&gt;] sch_direct_xmit+0xfe/0x2a0
  [&lt;ffffffff8157a249&gt;] dev_queue_xmit+0x199/0x830
  [&lt;ffffffff8157a0b0&gt;] ? netdev_pick_tx+0x570/0x570
  [&lt;ffffffff815ba96f&gt;] ip_finish_output+0x5df/0x870
  [&lt;ffffffff815ba4bd&gt;] ? ip_finish_output+0x12d/0x870
  [&lt;ffffffff815bb964&gt;] ip_output+0x54/0xf0
  [&lt;ffffffff815bad48&gt;] ip_local_out+0x28/0x90
  [&lt;ffffffff815bc444&gt;] ip_send_skb+0x14/0x50
  [&lt;ffffffff815bc4b2&gt;] ip_push_pending_frames+0x32/0x40
  [&lt;ffffffff815e536a&gt;] raw_sendmsg+0x93a/0xc30
  [&lt;ffffffff8128d570&gt;] ? selinux_file_send_sigiotask+0x1f0/0x1f0
  [&lt;ffffffff8109ddb4&gt;] ? __lock_is_held+0x54/0x80
  [&lt;ffffffff815f6730&gt;] ? inet_recvmsg+0x220/0x220
  [&lt;ffffffff8109ddb4&gt;] ? __lock_is_held+0x54/0x80
  [&lt;ffffffff815f6855&gt;] inet_sendmsg+0x125/0x240
  [&lt;ffffffff815f6730&gt;] ? inet_recvmsg+0x220/0x220
  [&lt;ffffffff8155cddb&gt;] sock_sendmsg+0xab/0xe0
  [&lt;ffffffff810a1650&gt;] ? lock_release_non_nested+0xa0/0x2e0
  [&lt;ffffffff810a1650&gt;] ? lock_release_non_nested+0xa0/0x2e0
  [&lt;ffffffff8155d18c&gt;] __sys_sendmsg+0x37c/0x390
  [&lt;ffffffff81195b2a&gt;] ? fsnotify+0x2ca/0x7e0
  [&lt;ffffffff811958e8&gt;] ? fsnotify+0x88/0x7e0
  [&lt;ffffffff81361f36&gt;] ? put_ldisc+0x56/0xd0
  [&lt;ffffffff8116f98a&gt;] ? fget_light+0x3da/0x510
  [&lt;ffffffff8155f6c4&gt;] sys_sendmsg+0x44/0x80
  [&lt;ffffffff8172fc22&gt;] system_call_fastpath+0x16/0x1b

Avoid this problem using a distinct lock_class_key for bonding
devices.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Cc: Andy Gospodarek &lt;andy@greyhouse.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: add some slack to arp monitoring time limits</title>
<updated>2012-08-31T20:37:12+00:00</updated>
<author>
<name>Jiri Bohac</name>
<email>jbohac@suse.cz</email>
</author>
<published>2012-08-30T12:02:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=da210f559019ba1cd4ebee2a28ad158bfb95bab2'/>
<id>da210f559019ba1cd4ebee2a28ad158bfb95bab2</id>
<content type='text'>
Currently, all the time limits in the bonding ARP monitor are in
multiples of arp_interval -- the time interval at which the ARP
monitor is periodically scheduled.

With a fast network round-trip and a little scheduling latency
of the ARP monitor work, a limit of n*delta_in_ticks may
effectively mean (n-1)*delta_in_ticks.

This is fatal in case of n==1  (the link will stay down
forever) and makes the behaviour non-deterministic in all the
other cases.

Add a delta_in_ticks/2 time slack to all the time limits.

Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&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>
Currently, all the time limits in the bonding ARP monitor are in
multiples of arp_interval -- the time interval at which the ARP
monitor is periodically scheduled.

With a fast network round-trip and a little scheduling latency
of the ARP monitor work, a limit of n*delta_in_ticks may
effectively mean (n-1)*delta_in_ticks.

This is fatal in case of n==1  (the link will stay down
forever) and makes the behaviour non-deterministic in all the
other cases.

Add a delta_in_ticks/2 time slack to all the time limits.

Signed-off-by: Jiri Bohac &lt;jbohac@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>bonding: support for IPv6 transmit hashing</title>
<updated>2012-08-23T05:49:30+00:00</updated>
<author>
<name>John Eaglesham</name>
<email>linux@8192.net</email>
</author>
<published>2012-08-21T20:43:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6b923cb7188d46905f43fa84210c4c3e5f9cd8fb'/>
<id>6b923cb7188d46905f43fa84210c4c3e5f9cd8fb</id>
<content type='text'>
Currently the "bonding" driver does not support load balancing outgoing
traffic in LACP mode for IPv6 traffic. IPv4 (and TCP or UDP over IPv4)
are currently supported; this patch adds transmit hashing for IPv6 (and
TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the
bonding driver. In addition, bounds checking has been added to all
transmit hashing functions.

The algorithm chosen (xor'ing the bottom three quads of the source and
destination addresses together, then xor'ing each byte of that result into
the bottom byte, finally xor'ing with the last bytes of the MAC addresses)
was selected after testing almost 400,000 unique IPv6 addresses harvested
from server logs. This algorithm had the most even distribution for both
big- and little-endian architectures while still using few instructions. Its
behavior also attempts to closely match that of the IPv4 algorithm.

The IPv6 flow label was intentionally not included in the hash as it appears
to be unset in the vast majority of IPv6 traffic sampled, and the current
algorithm not using the flow label already offers a very even distribution.

Fragmented IPv6 packets are handled the same way as fragmented IPv4 packets,
ie, they are not balanced based on layer 4 information. Additionally,
IPv6 packets with intermediate headers are not balanced based on layer
4 information. In practice these intermediate headers are not common and
this should not cause any problems, and the alternative (a packet-parsing
loop and look-up table) seemed slow and complicated for little gain.

Tested-by: John Eaglesham &lt;linux@8192.net&gt;
Signed-off-by: John Eaglesham &lt;linux@8192.net&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>
Currently the "bonding" driver does not support load balancing outgoing
traffic in LACP mode for IPv6 traffic. IPv4 (and TCP or UDP over IPv4)
are currently supported; this patch adds transmit hashing for IPv6 (and
TCP or UDP over IPv6), bringing IPv6 up to par with IPv4 support in the
bonding driver. In addition, bounds checking has been added to all
transmit hashing functions.

The algorithm chosen (xor'ing the bottom three quads of the source and
destination addresses together, then xor'ing each byte of that result into
the bottom byte, finally xor'ing with the last bytes of the MAC addresses)
was selected after testing almost 400,000 unique IPv6 addresses harvested
from server logs. This algorithm had the most even distribution for both
big- and little-endian architectures while still using few instructions. Its
behavior also attempts to closely match that of the IPv4 algorithm.

The IPv6 flow label was intentionally not included in the hash as it appears
to be unset in the vast majority of IPv6 traffic sampled, and the current
algorithm not using the flow label already offers a very even distribution.

Fragmented IPv6 packets are handled the same way as fragmented IPv4 packets,
ie, they are not balanced based on layer 4 information. Additionally,
IPv6 packets with intermediate headers are not balanced based on layer
4 information. In practice these intermediate headers are not common and
this should not cause any problems, and the alternative (a packet-parsing
loop and look-up table) seemed slow and complicated for little gain.

Tested-by: John Eaglesham &lt;linux@8192.net&gt;
Signed-off-by: John Eaglesham &lt;linux@8192.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
