<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net, branch v3.8.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>6lowpan: Remove __init tag from lowpan_netlink_fini().</title>
<updated>2013-03-14T18:26:37+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2013-02-06T20:54:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3bc7100a73bb90ad7aa4ca6b65b43dcc88343bb2'/>
<id>3bc7100a73bb90ad7aa4ca6b65b43dcc88343bb2</id>
<content type='text'>
commit a07fdceccf9d9f1b87f781e9a87662182e590d70 upstream.

It's called from both __init and __exit code, so neither
tag is appropriate.

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>
commit a07fdceccf9d9f1b87f781e9a87662182e590d70 upstream.

It's called from both __init and __exit code, so neither
tag is appropriate.

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>mac80211: Fix crash due to un-canceled work-items</title>
<updated>2013-03-14T18:26:25+00:00</updated>
<author>
<name>Ben Greear</name>
<email>greearb@candelatech.com</email>
</author>
<published>2013-02-20T17:41:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3bd535950181900d349d0d453ea97e5efd23a275'/>
<id>3bd535950181900d349d0d453ea97e5efd23a275</id>
<content type='text'>
commit 499218595a2e8296b7492af32fcca141b7b8184a upstream.

Some mlme work structs are not cancelled on disassociation
nor interface deletion, which leads to them running after
the memory has been freed

There is not a clean way to cancel these in the disassociation
logic because they must be canceled outside of the ifmgd-&gt;mtx
lock, so just cancel them in mgd_stop logic that tears down
the station.

This fixes the crashes we see in 3.7.9+.  The crash stack
trace itself isn't so helpful, but this warning gives
more useful info:

WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211]
Modules linked in: [...]
Pid: 14743, comm: iw Tainted: G         C O 3.7.9+ #11
Call Trace:
 [&lt;ffffffff81087ef8&gt;] warn_slowpath_common+0x80/0x98
 [&lt;ffffffff81087fa4&gt;] warn_slowpath_fmt+0x41/0x43
 [&lt;ffffffff812a2608&gt;] debug_print_object+0x7c/0x8d
 [&lt;ffffffff812a2bca&gt;] debug_check_no_obj_freed+0x95/0x1c3
 [&lt;ffffffff8114cc69&gt;] slab_free_hook+0x70/0x79
 [&lt;ffffffff8114ea3e&gt;] kfree+0x62/0xb7
 [&lt;ffffffff8149f465&gt;] netdev_release+0x39/0x3e
 [&lt;ffffffff8136ad67&gt;] device_release+0x52/0x8a
 [&lt;ffffffff812937db&gt;] kobject_release+0x121/0x158
 [&lt;ffffffff81293612&gt;] kobject_put+0x4c/0x50
 [&lt;ffffffff8148f0d7&gt;] netdev_run_todo+0x25c/0x27e

Signed-off-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&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>
commit 499218595a2e8296b7492af32fcca141b7b8184a upstream.

Some mlme work structs are not cancelled on disassociation
nor interface deletion, which leads to them running after
the memory has been freed

There is not a clean way to cancel these in the disassociation
logic because they must be canceled outside of the ifmgd-&gt;mtx
lock, so just cancel them in mgd_stop logic that tears down
the station.

This fixes the crashes we see in 3.7.9+.  The crash stack
trace itself isn't so helpful, but this warning gives
more useful info:

WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211]
Modules linked in: [...]
Pid: 14743, comm: iw Tainted: G         C O 3.7.9+ #11
Call Trace:
 [&lt;ffffffff81087ef8&gt;] warn_slowpath_common+0x80/0x98
 [&lt;ffffffff81087fa4&gt;] warn_slowpath_fmt+0x41/0x43
 [&lt;ffffffff812a2608&gt;] debug_print_object+0x7c/0x8d
 [&lt;ffffffff812a2bca&gt;] debug_check_no_obj_freed+0x95/0x1c3
 [&lt;ffffffff8114cc69&gt;] slab_free_hook+0x70/0x79
 [&lt;ffffffff8114ea3e&gt;] kfree+0x62/0xb7
 [&lt;ffffffff8149f465&gt;] netdev_release+0x39/0x3e
 [&lt;ffffffff8136ad67&gt;] device_release+0x52/0x8a
 [&lt;ffffffff812937db&gt;] kobject_release+0x121/0x158
 [&lt;ffffffff81293612&gt;] kobject_put+0x4c/0x50
 [&lt;ffffffff8148f0d7&gt;] netdev_run_todo+0x25c/0x27e

Signed-off-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>SUNRPC: Don't start the retransmission timer when out of socket space</title>
<updated>2013-03-14T18:26:12+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2013-02-22T19:57:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1c0d40a55ba1dba9513a1796c26ebcb1b09e4d1'/>
<id>f1c0d40a55ba1dba9513a1796c26ebcb1b09e4d1</id>
<content type='text'>
commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream.

If the socket is full, we're better off just waiting until it empties,
or until the connection is broken. The reason why we generally don't
want to time out is that the call to xprt-&gt;ops-&gt;release_xprt() will
trigger a connection reset, which isn't helpful...

Let's make an exception for soft RPC calls, since they have to provide
timeout guarantees.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&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>
commit a9a6b52ee1baa865283a91eb8d443ee91adfca56 upstream.

If the socket is full, we're better off just waiting until it empties,
or until the connection is broken. The reason why we generally don't
want to time out is that the call to xprt-&gt;ops-&gt;release_xprt() will
trigger a connection reset, which isn't helpful...

Let's make an exception for soft RPC calls, since they have to provide
timeout guarantees.

Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>svcrpc: fix rpc server shutdown races</title>
<updated>2013-03-03T22:03:37+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2013-02-10T21:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=acb9bc5fb5a7fb6051002633a430c1a977388912'/>
<id>acb9bc5fb5a7fb6051002633a430c1a977388912</id>
<content type='text'>
commit cc630d9f476445927fca599f81182c7f06f79058 upstream.

Rewrite server shutdown to remove the assumption that there are no
longer any threads running (no longer true, for example, when shutting
down the service in one network namespace while it's still running in
others).

Do that by doing what we'd do in normal circumstances: just CLOSE each
socket, then enqueue it.

Since there may not be threads to handle the resulting queued xprts,
also run a simplified version of the svc_recv() loop run by a server to
clean up any closed xprts afterwards.

Tested-by: Jason Tibbitts &lt;tibbs@math.uh.edu&gt;
Tested-by: Paweł Sikora &lt;pawel.sikora@agmk.net&gt;
Acked-by: Stanislav Kinsbursky &lt;skinsbursky@parallels.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&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>
commit cc630d9f476445927fca599f81182c7f06f79058 upstream.

Rewrite server shutdown to remove the assumption that there are no
longer any threads running (no longer true, for example, when shutting
down the service in one network namespace while it's still running in
others).

Do that by doing what we'd do in normal circumstances: just CLOSE each
socket, then enqueue it.

Since there may not be threads to handle the resulting queued xprts,
also run a simplified version of the svc_recv() loop run by a server to
clean up any closed xprts afterwards.

Tested-by: Jason Tibbitts &lt;tibbs@math.uh.edu&gt;
Tested-by: Paweł Sikora &lt;pawel.sikora@agmk.net&gt;
Acked-by: Stanislav Kinsbursky &lt;skinsbursky@parallels.com&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>svcrpc: make svc_age_temp_xprts enqueue under sv_lock</title>
<updated>2013-03-03T22:03:37+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2013-02-10T16:33:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cc5e7bc758e2d0e06d2b21ca0fd13144210735e5'/>
<id>cc5e7bc758e2d0e06d2b21ca0fd13144210735e5</id>
<content type='text'>
commit e75bafbff2270993926abcc31358361db74a9bc2 upstream.

svc_age_temp_xprts expires xprts in a two-step process: first it takes
the sv_lock and moves the xprts to expire off their server-wide list
(sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
sv_lock and enqueues and puts each one.

I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
sv_lock and sp_lock are not otherwise nested anywhere (and documentation
at the top of this file claims it's correct to nest these with sp_lock
inside.)

Tested-by: Jason Tibbitts &lt;tibbs@math.uh.edu&gt;
Tested-by: Paweł Sikora &lt;pawel.sikora@agmk.net&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&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>
commit e75bafbff2270993926abcc31358361db74a9bc2 upstream.

svc_age_temp_xprts expires xprts in a two-step process: first it takes
the sv_lock and moves the xprts to expire off their server-wide list
(sv_tempsocks or sv_permsocks) to a local list.  Then it drops the
sv_lock and enqueues and puts each one.

I see no reason for this: svc_xprt_enqueue() will take sp_lock, but the
sv_lock and sp_lock are not otherwise nested anywhere (and documentation
at the top of this file claims it's correct to nest these with sp_lock
inside.)

Tested-by: Jason Tibbitts &lt;tibbs@math.uh.edu&gt;
Tested-by: Paweł Sikora &lt;pawel.sikora@agmk.net&gt;
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: always unblock CSA queue stop when disconnecting</title>
<updated>2013-02-28T13:38:41+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-02-26T21:37:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=98091839ad5b72f8aa2c9b22ed65cec6fa3bbf6f'/>
<id>98091839ad5b72f8aa2c9b22ed65cec6fa3bbf6f</id>
<content type='text'>
Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream.

In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.

Fix this by always unblocking the queue CSA reason when

disconnecting.

Reported-by: Jan-Michael Brummer &lt;jan.brummer@tabos.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&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>
Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream.

In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.

Fix this by always unblocking the queue CSA reason when

disconnecting.

Reported-by: Jan-Michael Brummer &lt;jan.brummer@tabos.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sock_diag: Fix out-of-bounds access to sock_diag_handlers[]</title>
<updated>2013-02-28T13:38:41+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@googlemail.com</email>
</author>
<published>2013-02-23T01:13:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7bd46285b2bc213bb124a1ce995793a5788e3b36'/>
<id>7bd46285b2bc213bb124a1ce995793a5788e3b36</id>
<content type='text'>
[ Upstream commit 6e601a53566d84e1ffd25e7b6fe0b6894ffd79c0 ]

Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.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 6e601a53566d84e1ffd25e7b6fe0b6894ffd79c0 ]

Userland can send a netlink message requesting SOCK_DIAG_BY_FAMILY
with a family greater or equal then AF_MAX -- the array size of
sock_diag_handlers[]. The current code does not test for this
condition therefore is vulnerable to an out-of-bound access opening
doors for a privilege escalation.

Signed-off-by: Mathias Krause &lt;minipli@googlemail.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.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>tcp: fix SYN-data space mis-accounting</title>
<updated>2013-02-28T13:38:41+00:00</updated>
<author>
<name>Yuchung Cheng</name>
<email>ycheng@google.com</email>
</author>
<published>2013-02-22T08:59:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=46983ccad157df0e6dfa910b5255de6ddee35f04'/>
<id>46983ccad157df0e6dfa910b5255de6ddee35f04</id>
<content type='text'>
[ Upstream commit 1b63edd6ecc55c3a61b40297b49e2323783bddfd ]

In fast open the sender unncessarily reduces the space available
for data in SYN by 12 bytes.  This is because in the sender
incorrectly reserves space for TS option twice in tcp_send_syn_data():
tcp_mtu_to_mss() already accounts for TS option space. But it further
reserves MAX_TCP_OPTION_SPACE when computing the payload space.

Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.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 1b63edd6ecc55c3a61b40297b49e2323783bddfd ]

In fast open the sender unncessarily reduces the space available
for data in SYN by 12 bytes.  This is because in the sender
incorrectly reserves space for TS option twice in tcp_send_syn_data():
tcp_mtu_to_mss() already accounts for TS option space. But it further
reserves MAX_TCP_OPTION_SPACE when computing the payload space.

Signed-off-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.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>ipv4: fix error handling in icmp_protocol.</title>
<updated>2013-02-28T13:38:41+00:00</updated>
<author>
<name>Li Wei</name>
<email>lw@cn.fujitsu.com</email>
</author>
<published>2013-02-21T22:18:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=88bb40ba28f2ff6baf103b084eaaca8974b0a915'/>
<id>88bb40ba28f2ff6baf103b084eaaca8974b0a915</id>
<content type='text'>
[ Upstream commit 5b0520425e5ea81ba95ec486dd6bbb59a09fff0e ]

Now we handle icmp errors in each transport protocol's err_handler,
for icmp protocols, that is ping_err. Since this handler only care
of those icmp errors triggered by echo request, errors triggered
by echo reply(which sent by kernel) are sliently ignored.

So wrap ping_err() with icmp_err() to deal with those icmp errors.

Signed-off-by: Li Wei &lt;lw@cn.fujitsu.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 5b0520425e5ea81ba95ec486dd6bbb59a09fff0e ]

Now we handle icmp errors in each transport protocol's err_handler,
for icmp protocols, that is ping_err. Since this handler only care
of those icmp errors triggered by echo request, errors triggered
by echo reply(which sent by kernel) are sliently ignored.

So wrap ping_err() with icmp_err() to deal with those icmp errors.

Signed-off-by: Li Wei &lt;lw@cn.fujitsu.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>ipv6: use a stronger hash for tcp</title>
<updated>2013-02-28T13:38:41+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-02-21T12:18:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7e122d3c7c52acfa96c2939db26e7fd3cc96a651'/>
<id>7e122d3c7c52acfa96c2939db26e7fd3cc96a651</id>
<content type='text'>
[ Upstream commit 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ]

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Yuchung Cheng &lt;ycheng@google.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 08dcdbf6a7b9d14c2302c5bd0c5390ddf122f664 ]

It looks like its possible to open thousands of TCP IPv6
sessions on a server, all landing in a single slot of TCP hash
table. Incoming packets have to lookup sockets in a very
long list.

We should hash all bits from foreign IPv6 addresses, using
a salt and hash mix, not a simple XOR.

inet6_ehashfn() can also separately use the ports, instead
of xoring them.

Reported-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Yuchung Cheng &lt;ycheng@google.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>
</feed>
