<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net, branch v3.13-rc3</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2013-12-02T18:09:07+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-12-02T18:09:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5fc92de3c7106d17f85c245383ba072d810d6bb0'/>
<id>5fc92de3c7106d17f85c245383ba072d810d6bb0</id>
<content type='text'>
Pull networking updates from David Miller:
 "Here is a pile of bug fixes that accumulated while I was in Europe"

 1) In fixing kernel leaks to userspace during copying of socket
    addresses, we broke a case that used to work, namely the user
    providing a buffer larger than the in-kernel generic socket address
    structure.  This broke Ruby amongst other things.  Fix from Dan
    Carpenter.

 2) Fix regression added by byte queue limit support in 8139cp driver,
    from Yang Yingliang.

 3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
    implementations, they should just treat it the same as MSG_MORE.
    Fix from Richard Weinberger and Shawn Landden.

 4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
    Oussama Ghorbel.  In particular we should send an ICMPv6 unreachable
    in such situations.

 5) Fix some regressions in the recent genetlink fixes, in particular
    get the pmcraid driver to use the new safer interfaces correctly.
    From Johannes Berg.

 6) macvtap was converted to use a per-cpu set of statistics, but some
    code was still bumping tx_dropped elsewhere.  From Jason Wang.

 7) Fix build failure of xen-netback due to missing include on some
    architectures, from Andy Whitecroft.

 8) macvtap double counts received packets in statistics, fix from Vlad
    Yasevich.

 9) Fix various cases of using *_STATS_BH() when *_STATS() is more
    appropriate.  From Eric Dumazet and Hannes Frederic Sowa.

10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
    properly after encapsulation.  Fix from Fan Du.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
  net/mlx4_en: Remove selftest TX queues empty condition
  {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
  virtio_net: make all RX paths handle erors consistently
  virtio_net: fix error handling for mergeable buffers
  virtio_net: Fixed a trivial typo (fitler --&gt; filter)
  netem: fix gemodel loss generator
  netem: fix loss 4 state model
  netem: missing break in ge loss generator
  net/hsr: Support iproute print_opt ('ip -details ...')
  net/hsr: Very small fix of comment style.
  MAINTAINERS: Added net/hsr/ maintainer
  ipv6: fix possible seqlock deadlock in ip6_finish_output2
  ixgbe: Make ixgbe_identify_qsfp_module_generic static
  ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
  ixgbe: ixgbe_fwd_ring_down needs to be static
  e1000: fix possible reset_task running after adapter down
  e1000: fix lockdep warning in e1000_reset_task
  e1000: prevent oops when adapter is being closed and reset simultaneously
  igb: Fixed Wake On LAN support
  inet: fix possible seqlock deadlocks
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull networking updates from David Miller:
 "Here is a pile of bug fixes that accumulated while I was in Europe"

 1) In fixing kernel leaks to userspace during copying of socket
    addresses, we broke a case that used to work, namely the user
    providing a buffer larger than the in-kernel generic socket address
    structure.  This broke Ruby amongst other things.  Fix from Dan
    Carpenter.

 2) Fix regression added by byte queue limit support in 8139cp driver,
    from Yang Yingliang.

 3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
    implementations, they should just treat it the same as MSG_MORE.
    Fix from Richard Weinberger and Shawn Landden.

 4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
    Oussama Ghorbel.  In particular we should send an ICMPv6 unreachable
    in such situations.

 5) Fix some regressions in the recent genetlink fixes, in particular
    get the pmcraid driver to use the new safer interfaces correctly.
    From Johannes Berg.

 6) macvtap was converted to use a per-cpu set of statistics, but some
    code was still bumping tx_dropped elsewhere.  From Jason Wang.

 7) Fix build failure of xen-netback due to missing include on some
    architectures, from Andy Whitecroft.

 8) macvtap double counts received packets in statistics, fix from Vlad
    Yasevich.

 9) Fix various cases of using *_STATS_BH() when *_STATS() is more
    appropriate.  From Eric Dumazet and Hannes Frederic Sowa.

10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
    properly after encapsulation.  Fix from Fan Du.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
  net/mlx4_en: Remove selftest TX queues empty condition
  {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
  virtio_net: make all RX paths handle erors consistently
  virtio_net: fix error handling for mergeable buffers
  virtio_net: Fixed a trivial typo (fitler --&gt; filter)
  netem: fix gemodel loss generator
  netem: fix loss 4 state model
  netem: missing break in ge loss generator
  net/hsr: Support iproute print_opt ('ip -details ...')
  net/hsr: Very small fix of comment style.
  MAINTAINERS: Added net/hsr/ maintainer
  ipv6: fix possible seqlock deadlock in ip6_finish_output2
  ixgbe: Make ixgbe_identify_qsfp_module_generic static
  ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
  ixgbe: ixgbe_fwd_ring_down needs to be static
  e1000: fix possible reset_task running after adapter down
  e1000: fix lockdep warning in e1000_reset_task
  e1000: prevent oops when adapter is being closed and reset simultaneously
  igb: Fixed Wake On LAN support
  inet: fix possible seqlock deadlocks
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>net/mlx4_en: Remove selftest TX queues empty condition</title>
<updated>2013-12-02T01:36:07+00:00</updated>
<author>
<name>Eugenia Emantayev</name>
<email>eugenia@mellanox.com</email>
</author>
<published>2013-12-01T12:19:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=833846e8fa0c51fb3e47bca8adfdd7b10643b737'/>
<id>833846e8fa0c51fb3e47bca8adfdd7b10643b737</id>
<content type='text'>
Remove waiting for TX queues to become empty during selftest.
This check is not necessary for any purpose, and might put
the driver into an infinite loop.

Signed-off-by: Eugenia Emantayev &lt;eugenia@mellanox.com&gt;
Signed-off-by: Amir Vadai &lt;amirv@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>
Remove waiting for TX queues to become empty during selftest.
This check is not necessary for any purpose, and might put
the driver into an infinite loop.

Signed-off-by: Eugenia Emantayev &lt;eugenia@mellanox.com&gt;
Signed-off-by: Amir Vadai &lt;amirv@mellanox.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_net: make all RX paths handle erors consistently</title>
<updated>2013-12-02T01:27:16+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2013-11-28T11:30:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f121159d72091f25afb22007c833e60a6845e912'/>
<id>f121159d72091f25afb22007c833e60a6845e912</id>
<content type='text'>
receive mergeable now handles errors internally.
Do same for big and small packet paths, otherwise
the logic is too hard to follow.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@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>
receive mergeable now handles errors internally.
Do same for big and small packet paths, otherwise
the logic is too hard to follow.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_net: fix error handling for mergeable buffers</title>
<updated>2013-12-02T01:27:16+00:00</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2013-11-28T11:30:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8fc3b9e9a229778e5af3aa453c44f1a3857ba769'/>
<id>8fc3b9e9a229778e5af3aa453c44f1a3857ba769</id>
<content type='text'>
Eric Dumazet noticed that if we encounter an error
when processing a mergeable buffer, we don't
dequeue all of the buffers from this packet,
the result is almost sure to be loss of networking.

Jason Wang noticed that we also leak a page and that we don't decrement
the rq buf count, so we won't repost buffers (a resource leak).

Fix both issues.

Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Michael Dalton &lt;mwdalton@google.com&gt;
Reported-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@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>
Eric Dumazet noticed that if we encounter an error
when processing a mergeable buffer, we don't
dequeue all of the buffers from this packet,
the result is almost sure to be loss of networking.

Jason Wang noticed that we also leak a page and that we don't decrement
the rq buf count, so we won't repost buffers (a resource leak).

Fix both issues.

Cc: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Cc: Michael Dalton &lt;mwdalton@google.com&gt;
Reported-by: Eric Dumazet &lt;edumazet@google.com&gt;
Reported-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Jason Wang &lt;jasowang@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>virtio_net: Fixed a trivial typo (fitler --&gt; filter)</title>
<updated>2013-11-30T21:14:24+00:00</updated>
<author>
<name>Thomas Huth</name>
<email>thuth@linux.vnet.ibm.com</email>
</author>
<published>2013-11-29T09:02:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=99e872ae1eacb560152c0123cf1cef571569e681'/>
<id>99e872ae1eacb560152c0123cf1cef571569e681</id>
<content type='text'>
"MAC filter" sounds more reasonable than "MAC fitler".

Signed-off-by: Thomas Huth &lt;thuth@linux.vnet.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>
"MAC filter" sounds more reasonable than "MAC fitler".

Signed-off-by: Thomas Huth &lt;thuth@linux.vnet.ibm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: Make ixgbe_identify_qsfp_module_generic static</title>
<updated>2013-11-30T08:21:47+00:00</updated>
<author>
<name>Mark Rustad</name>
<email>mark.d.rustad@intel.com</email>
</author>
<published>2013-11-23T03:19:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8821754704a661623083a9dedf425114199600ba'/>
<id>8821754704a661623083a9dedf425114199600ba</id>
<content type='text'>
Correct a namespace complaint by making the function static
and moving the prototype into the .c file.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Correct a namespace complaint by making the function static
and moving the prototype into the .c file.

Signed-off-by: Mark Rustad &lt;mark.d.rustad@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default</title>
<updated>2013-11-30T08:15:16+00:00</updated>
<author>
<name>John Fastabend</name>
<email>john.r.fastabend@intel.com</email>
</author>
<published>2013-11-12T12:13:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8bf1264d2f12c6fa8645d097275568c1b62c246c'/>
<id>8bf1264d2f12c6fa8645d097275568c1b62c246c</id>
<content type='text'>
NETIF_F_HW_L2FW_DOFFLOAD allows upper layer net devices such
as macvlan to use queues in the hardware to directly submit and
receive skbs.

This creates a subtle change in the datapath though. One change
being the skb may no longer use the root devices qdisc.

Because users may not expect this we can't enable the feature
by default unless the hardware can offload all the software
functionality above it. So for now disable it by default and
let users opt in.

Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
NETIF_F_HW_L2FW_DOFFLOAD allows upper layer net devices such
as macvlan to use queues in the hardware to directly submit and
receive skbs.

This creates a subtle change in the datapath though. One change
being the skb may no longer use the root devices qdisc.

Because users may not expect this we can't enable the feature
by default unless the hardware can offload all the software
functionality above it. So for now disable it by default and
let users opt in.

Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ixgbe: ixgbe_fwd_ring_down needs to be static</title>
<updated>2013-11-30T08:08:45+00:00</updated>
<author>
<name>John Fastabend</name>
<email>john.r.fastabend@intel.com</email>
</author>
<published>2013-11-09T07:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ae72c8d068b3440c0b45df284303794cfbc0f4f2'/>
<id>ae72c8d068b3440c0b45df284303794cfbc0f4f2</id>
<content type='text'>
When compiling with -Wstrict-prototypes gcc catches a static
I missed.

./ixgbe_main.c:4254: warning: no previous prototype for 'ixgbe_fwd_ring_down'

Reported-by: Phillip Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When compiling with -Wstrict-prototypes gcc catches a static
I missed.

./ixgbe_main.c:4254: warning: no previous prototype for 'ixgbe_fwd_ring_down'

Reported-by: Phillip Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Tested-by: Phil Schmitt &lt;phillip.j.schmitt@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000: fix possible reset_task running after adapter down</title>
<updated>2013-11-30T08:02:12+00:00</updated>
<author>
<name>Vladimir Davydov</name>
<email>VDavydov@parallels.com</email>
</author>
<published>2013-11-23T07:18:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=74a1b1ea8a30b035aaad833bbd6b9263e72acfac'/>
<id>74a1b1ea8a30b035aaad833bbd6b9263e72acfac</id>
<content type='text'>
On e1000_down(), we should ensure every asynchronous work is canceled
before proceeding. Since the watchdog_task can schedule other works
apart from itself, it should be stopped first, but currently it is
stopped after the reset_task. This can result in the following race
leading to the reset_task running after the module unload:

e1000_down_and_stop():			e1000_watchdog():
----------------------			-----------------

cancel_work_sync(reset_task)
					schedule_work(reset_task)
cancel_delayed_work_sync(watchdog_task)

The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning
of e1000_down_and_stop() thus ensuring the race is impossible.

Cc: Tushar Dave &lt;tushar.n.dave@intel.com&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Vladimir Davydov &lt;vdavydov@parallels.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On e1000_down(), we should ensure every asynchronous work is canceled
before proceeding. Since the watchdog_task can schedule other works
apart from itself, it should be stopped first, but currently it is
stopped after the reset_task. This can result in the following race
leading to the reset_task running after the module unload:

e1000_down_and_stop():			e1000_watchdog():
----------------------			-----------------

cancel_work_sync(reset_task)
					schedule_work(reset_task)
cancel_delayed_work_sync(watchdog_task)

The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning
of e1000_down_and_stop() thus ensuring the race is impossible.

Cc: Tushar Dave &lt;tushar.n.dave@intel.com&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Vladimir Davydov &lt;vdavydov@parallels.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000: fix lockdep warning in e1000_reset_task</title>
<updated>2013-11-30T07:55:40+00:00</updated>
<author>
<name>Vladimir Davydov</name>
<email>VDavydov@parallels.com</email>
</author>
<published>2013-11-23T07:17:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b2f963bfaebadc9117b29f806630ea3bcaec403d'/>
<id>b2f963bfaebadc9117b29f806630ea3bcaec403d</id>
<content type='text'>
The patch fixes the following lockdep warning, which is 100%
reproducible on network restart:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0+ #47 Tainted: GF
-------------------------------------------------------
kworker/1:1/27 is trying to acquire lock:
 ((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+...}, at: [&lt;ffffffff8108a5b0&gt;] flush_work+0x0/0x70

but task is already holding lock:
 (&amp;adapter-&gt;mutex){+.+...}, at: [&lt;ffffffffa0177c0a&gt;] e1000_reset_task+0x4a/0xa0 [e1000]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;adapter-&gt;mutex){+.+...}:
       [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
       [&lt;ffffffff816b8cbc&gt;] mutex_lock_nested+0x4c/0x390
       [&lt;ffffffffa017233d&gt;] e1000_watchdog+0x7d/0x5b0 [e1000]
       [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
       [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
       [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
       [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0

-&gt; #0 ((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+...}:
       [&lt;ffffffff810bd9c0&gt;] __lock_acquire+0x1710/0x1810
       [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
       [&lt;ffffffff8108a5eb&gt;] flush_work+0x3b/0x70
       [&lt;ffffffff8108b5d8&gt;] __cancel_work_timer+0x98/0x140
       [&lt;ffffffff8108b693&gt;] cancel_delayed_work_sync+0x13/0x20
       [&lt;ffffffffa0170cec&gt;] e1000_down_and_stop+0x3c/0x60 [e1000]
       [&lt;ffffffffa01775b1&gt;] e1000_down+0x131/0x220 [e1000]
       [&lt;ffffffffa0177c12&gt;] e1000_reset_task+0x52/0xa0 [e1000]
       [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
       [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
       [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
       [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;adapter-&gt;mutex);
                               lock((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work));
                               lock(&amp;adapter-&gt;mutex);
  lock((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work));

 *** DEADLOCK ***

3 locks held by kworker/1:1/27:
 #0:  (events){.+.+.+}, at: [&lt;ffffffff8108b906&gt;] process_one_work+0x166/0x510
 #1:  ((&amp;adapter-&gt;reset_task)){+.+...}, at: [&lt;ffffffff8108b906&gt;] process_one_work+0x166/0x510
 #2:  (&amp;adapter-&gt;mutex){+.+...}, at: [&lt;ffffffffa0177c0a&gt;] e1000_reset_task+0x4a/0xa0 [e1000]

stack backtrace:
CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF            3.12.0+ #47
Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS 0501    05/31/2007
Workqueue: events e1000_reset_task [e1000]
 ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
 ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
 ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
Call Trace:
 [&lt;ffffffff816b54a2&gt;] dump_stack+0x49/0x5f
 [&lt;ffffffff810ba936&gt;] print_circular_bug+0x216/0x310
 [&lt;ffffffff810bd9c0&gt;] __lock_acquire+0x1710/0x1810
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff8108a5eb&gt;] flush_work+0x3b/0x70
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff8108b5d8&gt;] __cancel_work_timer+0x98/0x140
 [&lt;ffffffff8108b693&gt;] cancel_delayed_work_sync+0x13/0x20
 [&lt;ffffffffa0170cec&gt;] e1000_down_and_stop+0x3c/0x60 [e1000]
 [&lt;ffffffffa01775b1&gt;] e1000_down+0x131/0x220 [e1000]
 [&lt;ffffffffa0177c12&gt;] e1000_reset_task+0x52/0xa0 [e1000]
 [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
 [&lt;ffffffff8108b906&gt;] ? process_one_work+0x166/0x510
 [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
 [&lt;ffffffff8108c960&gt;] ? manage_workers+0x2c0/0x2c0
 [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
 [&lt;ffffffff81092b30&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff81092b30&gt;] ? __init_kthread_worker+0x70/0x70

== The issue background ==

The problem occurs, because e1000_down(), which is called under
adapter-&gt;mutex by e1000_reset_task(), tries to synchronously cancel
e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
fifo_stall_task), which take adapter-&gt;mutex in their handlers. So the
question is what does adapter-&gt;mutex protect there?

The adapter-&gt;mutex was introduced by commit 0ef4ee ("e1000: convert to
private mutex from rtnl") as a replacement for rtnl_lock() taken in the
asynchronous handlers. It targeted on fixing a similar lockdep warning
issued when e1000_down() was called under rtnl_lock(), and it fixed it,
but unfortunately it introduced the lockdep warning described above.
Anyway, that said the source of this bug is that the asynchronous works
were made to take rtnl_lock() some time ago, so let's look deeper and
find why it was added there.

The rtnl_lock() was added to asynchronous handlers by commit 338c15
("e1000: fix occasional panic on unload") in order to prevent
asynchronous handlers from execution after the module is unloaded
(e1000_down() is called) as it follows from the comment to the commit:

&gt; Net drivers in general have an issue where timers fired
&gt; by mod_timer or work threads with schedule_work are running
&gt; outside of the rtnl_lock.
&gt;
&gt; With no other lock protection these routines are vulnerable
&gt; to races with driver unload or reset paths.
&gt;
&gt; The longer term solution to this might be a redesign with
&gt; safer locks being taken in the driver to guarantee no
&gt; reentrance, but for now a safe and effective fix is
&gt; to take the rtnl_lock in these routines.

I'm not sure if this locking scheme fixed the problem or just made it
unlikely, although I incline to the latter. Anyway, this was long time
ago when e1000 auxiliary works were implemented as timers scheduling
real work handlers in their routines. The e1000_down() function only
canceled the timers, but left the real handlers running if they were
running, which could result in work execution after module unload.
Today, the e1000 driver uses sane delayed works instead of the pair
timer+work to implement its delayed asynchronous handlers, and the
e1000_down() synchronously cancels all the works so that the problem
that commit 338c15 tried to cope with disappeared, and we don't need any
locks in the handlers any more. Moreover, any locking there can
potentially result in a deadlock.

So, this patch reverts commits 0ef4ee and 338c15.

Fixes: 0ef4eedc2e98 ("e1000: convert to private mutex from rtnl")
Fixes: 338c15e470d8 ("e1000: fix occasional panic on unload")
Cc: Tushar Dave &lt;tushar.n.dave@intel.com&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Vladimir Davydov &lt;vdavydov@parallels.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The patch fixes the following lockdep warning, which is 100%
reproducible on network restart:

======================================================
[ INFO: possible circular locking dependency detected ]
3.12.0+ #47 Tainted: GF
-------------------------------------------------------
kworker/1:1/27 is trying to acquire lock:
 ((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+...}, at: [&lt;ffffffff8108a5b0&gt;] flush_work+0x0/0x70

but task is already holding lock:
 (&amp;adapter-&gt;mutex){+.+...}, at: [&lt;ffffffffa0177c0a&gt;] e1000_reset_task+0x4a/0xa0 [e1000]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;adapter-&gt;mutex){+.+...}:
       [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
       [&lt;ffffffff816b8cbc&gt;] mutex_lock_nested+0x4c/0x390
       [&lt;ffffffffa017233d&gt;] e1000_watchdog+0x7d/0x5b0 [e1000]
       [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
       [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
       [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
       [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0

-&gt; #0 ((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+...}:
       [&lt;ffffffff810bd9c0&gt;] __lock_acquire+0x1710/0x1810
       [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
       [&lt;ffffffff8108a5eb&gt;] flush_work+0x3b/0x70
       [&lt;ffffffff8108b5d8&gt;] __cancel_work_timer+0x98/0x140
       [&lt;ffffffff8108b693&gt;] cancel_delayed_work_sync+0x13/0x20
       [&lt;ffffffffa0170cec&gt;] e1000_down_and_stop+0x3c/0x60 [e1000]
       [&lt;ffffffffa01775b1&gt;] e1000_down+0x131/0x220 [e1000]
       [&lt;ffffffffa0177c12&gt;] e1000_reset_task+0x52/0xa0 [e1000]
       [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
       [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
       [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
       [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;adapter-&gt;mutex);
                               lock((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work));
                               lock(&amp;adapter-&gt;mutex);
  lock((&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work));

 *** DEADLOCK ***

3 locks held by kworker/1:1/27:
 #0:  (events){.+.+.+}, at: [&lt;ffffffff8108b906&gt;] process_one_work+0x166/0x510
 #1:  ((&amp;adapter-&gt;reset_task)){+.+...}, at: [&lt;ffffffff8108b906&gt;] process_one_work+0x166/0x510
 #2:  (&amp;adapter-&gt;mutex){+.+...}, at: [&lt;ffffffffa0177c0a&gt;] e1000_reset_task+0x4a/0xa0 [e1000]

stack backtrace:
CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF            3.12.0+ #47
Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS 0501    05/31/2007
Workqueue: events e1000_reset_task [e1000]
 ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
 ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
 ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
Call Trace:
 [&lt;ffffffff816b54a2&gt;] dump_stack+0x49/0x5f
 [&lt;ffffffff810ba936&gt;] print_circular_bug+0x216/0x310
 [&lt;ffffffff810bd9c0&gt;] __lock_acquire+0x1710/0x1810
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff810bdb5d&gt;] lock_acquire+0x9d/0x120
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff8108a5eb&gt;] flush_work+0x3b/0x70
 [&lt;ffffffff8108a5b0&gt;] ? __flush_work+0x250/0x250
 [&lt;ffffffff8108b5d8&gt;] __cancel_work_timer+0x98/0x140
 [&lt;ffffffff8108b693&gt;] cancel_delayed_work_sync+0x13/0x20
 [&lt;ffffffffa0170cec&gt;] e1000_down_and_stop+0x3c/0x60 [e1000]
 [&lt;ffffffffa01775b1&gt;] e1000_down+0x131/0x220 [e1000]
 [&lt;ffffffffa0177c12&gt;] e1000_reset_task+0x52/0xa0 [e1000]
 [&lt;ffffffff8108b972&gt;] process_one_work+0x1d2/0x510
 [&lt;ffffffff8108b906&gt;] ? process_one_work+0x166/0x510
 [&lt;ffffffff8108ca80&gt;] worker_thread+0x120/0x3a0
 [&lt;ffffffff8108c960&gt;] ? manage_workers+0x2c0/0x2c0
 [&lt;ffffffff81092c1e&gt;] kthread+0xee/0x110
 [&lt;ffffffff81092b30&gt;] ? __init_kthread_worker+0x70/0x70
 [&lt;ffffffff816c3d7c&gt;] ret_from_fork+0x7c/0xb0
 [&lt;ffffffff81092b30&gt;] ? __init_kthread_worker+0x70/0x70

== The issue background ==

The problem occurs, because e1000_down(), which is called under
adapter-&gt;mutex by e1000_reset_task(), tries to synchronously cancel
e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
fifo_stall_task), which take adapter-&gt;mutex in their handlers. So the
question is what does adapter-&gt;mutex protect there?

The adapter-&gt;mutex was introduced by commit 0ef4ee ("e1000: convert to
private mutex from rtnl") as a replacement for rtnl_lock() taken in the
asynchronous handlers. It targeted on fixing a similar lockdep warning
issued when e1000_down() was called under rtnl_lock(), and it fixed it,
but unfortunately it introduced the lockdep warning described above.
Anyway, that said the source of this bug is that the asynchronous works
were made to take rtnl_lock() some time ago, so let's look deeper and
find why it was added there.

The rtnl_lock() was added to asynchronous handlers by commit 338c15
("e1000: fix occasional panic on unload") in order to prevent
asynchronous handlers from execution after the module is unloaded
(e1000_down() is called) as it follows from the comment to the commit:

&gt; Net drivers in general have an issue where timers fired
&gt; by mod_timer or work threads with schedule_work are running
&gt; outside of the rtnl_lock.
&gt;
&gt; With no other lock protection these routines are vulnerable
&gt; to races with driver unload or reset paths.
&gt;
&gt; The longer term solution to this might be a redesign with
&gt; safer locks being taken in the driver to guarantee no
&gt; reentrance, but for now a safe and effective fix is
&gt; to take the rtnl_lock in these routines.

I'm not sure if this locking scheme fixed the problem or just made it
unlikely, although I incline to the latter. Anyway, this was long time
ago when e1000 auxiliary works were implemented as timers scheduling
real work handlers in their routines. The e1000_down() function only
canceled the timers, but left the real handlers running if they were
running, which could result in work execution after module unload.
Today, the e1000 driver uses sane delayed works instead of the pair
timer+work to implement its delayed asynchronous handlers, and the
e1000_down() synchronously cancels all the works so that the problem
that commit 338c15 tried to cope with disappeared, and we don't need any
locks in the handlers any more. Moreover, any locking there can
potentially result in a deadlock.

So, this patch reverts commits 0ef4ee and 338c15.

Fixes: 0ef4eedc2e98 ("e1000: convert to private mutex from rtnl")
Fixes: 338c15e470d8 ("e1000: fix occasional panic on unload")
Cc: Tushar Dave &lt;tushar.n.dave@intel.com&gt;
Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Signed-off-by: Vladimir Davydov &lt;vdavydov@parallels.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
