<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.5.1</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.5.1</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.5.1'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-08-09T15:23:14Z</updated>
<entry>
<title>tcp: perform DMA to userspace only if there is a task waiting for it</title>
<updated>2012-08-09T15:23:14Z</updated>
<author>
<name>Jiri Kosina</name>
<email>jkosina@suse.cz</email>
</author>
<published>2012-07-27T10:38:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b35581f9e750bce76d305f2fb2551d3ab9cddede'/>
<id>urn:sha1:b35581f9e750bce76d305f2fb2551d3ab9cddede</id>
<content type='text'>
[ Upstream commit 59ea33a68a9083ac98515e4861c00e71efdc49a1 ]

Back in 2006, commit 1a2449a87b ("[I/OAT]: TCP recv offload to I/OAT")
added support for receive offloading to IOAT dma engine if available.

The code in tcp_rcv_established() tries to perform early DMA copy if
applicable. It however does so without checking whether the userspace
task is actually expecting the data in the buffer.

This is not a problem under normal circumstances, but there is a corner
case where this doesn't work -- and that's when MSG_TRUNC flag to
recvmsg() is used.

If the IOAT dma engine is not used, the code properly checks whether
there is a valid ucopy.task and the socket is owned by userspace, but
misses the check in the dmaengine case.

This problem can be observed in real trivially -- for example 'tbench' is a
good reproducer, as it makes a heavy use of MSG_TRUNC. On systems utilizing
IOAT, you will soon find tbench waiting indefinitely in sk_wait_data(), as they
have been already early-copied in tcp_rcv_established() using dma engine.

This patch introduces the same check we are performing in the simple
iovec copy case to the IOAT case as well. It fixes the indefinite
recvmsg(MSG_TRUNC) hangs.

Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: fix rtnetlink IFF_PROMISC and IFF_ALLMULTI handling</title>
<updated>2012-08-09T15:23:13Z</updated>
<author>
<name>Jiri Benc</name>
<email>jbenc@redhat.com</email>
</author>
<published>2012-07-27T02:58:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b71b10d6e9c2e3ddded0204be9b75719991a62b6'/>
<id>urn:sha1:b71b10d6e9c2e3ddded0204be9b75719991a62b6</id>
<content type='text'>
[ Upstream commit b1beb681cba5358f62e6187340660ade226a5fcc ]

When device flags are set using rtnetlink, IFF_PROMISC and IFF_ALLMULTI
flags are handled specially. Function dev_change_flags sets IFF_PROMISC and
IFF_ALLMULTI bits in dev-&gt;gflags according to the passed value but
do_setlink passes a result of rtnl_dev_combine_flags which takes those bits
from dev-&gt;flags.

This can be easily trigerred by doing:

tcpdump -i eth0 &amp;
ip l s up eth0

ip sets IFF_UP flag in ifi_flags and ifi_change, which is combined with
IFF_PROMISC by rtnl_dev_combine_flags, causing __dev_change_flags to set
IFF_PROMISC in gflags.

Reported-by: Max Matveev &lt;makc@redhat.com&gt;
Signed-off-by: Jiri Benc &lt;jbenc@redhat.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>
</entry>
<entry>
<title>tcp: Add TCP_USER_TIMEOUT negative value check</title>
<updated>2012-08-09T15:23:13Z</updated>
<author>
<name>Hangbin Liu</name>
<email>liuhangbin@gmail.com</email>
</author>
<published>2012-07-26T22:52:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae8effff91107fec667a7240d25978fe994da30b'/>
<id>urn:sha1:ae8effff91107fec667a7240d25978fe994da30b</id>
<content type='text'>
[ Upstream commit 42493570100b91ef663c4c6f0c0fdab238f9d3c2 ]

TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int. But
patch "tcp: Add TCP_USER_TIMEOUT socket option"(dca43c75) didn't check the negative
values. If a user assign -1 to it, the socket will set successfully and wait
for 4294967295 miliseconds. This patch add a negative value check to avoid
this issue.

Signed-off-by: Hangbin Liu &lt;liuhangbin@gmail.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>
</entry>
<entry>
<title>wanmain: comparing array with NULL</title>
<updated>2012-08-09T15:23:13Z</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-07-24T08:16:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a4631a7743f79abd92433e8b3da0cfb77d8c3b15'/>
<id>urn:sha1:a4631a7743f79abd92433e8b3da0cfb77d8c3b15</id>
<content type='text'>
[ Upstream commit 8b72ff6484fe303e01498b58621810a114f3cf09 ]

gcc really should warn about these !

Signed-off-by: Alan Cox &lt;alan@linux.intel.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>
</entry>
<entry>
<title>net: Fix references to out-of-scope variables in put_cmsg_compat()</title>
<updated>2012-08-09T15:23:13Z</updated>
<author>
<name>Jesper Juhl</name>
<email>jj@chaosbits.net</email>
</author>
<published>2012-07-22T11:37:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=806079ebdd18dacc3c4502a6f967a08e95b41379'/>
<id>urn:sha1:806079ebdd18dacc3c4502a6f967a08e95b41379</id>
<content type='text'>
[ Upstream commit 818810472b129004c16fc51bf0a570b60776bfb7 ]

In net/compat.c::put_cmsg_compat() we may assign 'data' the address of
either the 'ctv' or 'cts' local variables inside the 'if
(!COMPAT_USE_64BIT_TIME)' branch.

Those variables go out of scope at the end of the 'if' statement, so
when we use 'data' further down in 'copy_to_user(CMSG_COMPAT_DATA(cm),
data, cmlen - sizeof(struct compat_cmsghdr))' there's no telling what
it may be refering to - not good.

Fix the problem by simply giving 'ctv' and 'cts' function scope.

Signed-off-by: Jesper Juhl &lt;jj@chaosbits.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nfs: skip commit in releasepage if we're freeing memory for fs-related reasons</title>
<updated>2012-08-09T15:23:12Z</updated>
<author>
<name>Jeff Layton</name>
<email>jlayton@redhat.com</email>
</author>
<published>2012-07-23T17:58:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1e6ddec244966bc0c4322cfeb6200370eb1bc83e'/>
<id>urn:sha1:1e6ddec244966bc0c4322cfeb6200370eb1bc83e</id>
<content type='text'>
commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.

We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:

    PID: 2507   TASK: ffff88103691ab40  CPU: 14  COMMAND: "rpciod/14"
     #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
     #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
     #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
     #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
     #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
     #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
     #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
     #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
     #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
     #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
    #10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
    #11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
    #12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
    #13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
    #14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
    #15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
    #16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
    #17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
    #18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
    #19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
    #20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
    #21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
    #22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
    #23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
    #24 [ffff8810343bfee8] kthread at ffffffff8108dd96
    #25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca

rpciod is trying to allocate memory for a new socket to talk to the
server. The VM ends up calling -&gt;releasepage to get more memory, and it
tries to do a blocking commit. That commit can't succeed however without
a connected socket, so we deadlock.

Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
socket allocation, and having nfs_release_page check for that flag when
deciding whether to do a commit call. Also, set PF_FSTRANS
unconditionally in rpc_async_schedule since that function can also do
allocations sometimes.

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

</content>
</entry>
<entry>
<title>mac80211: fail authentication when AP denied authentication</title>
<updated>2012-08-09T15:22:52Z</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2012-05-13T15:07:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bd9f6140e697f52bdc7225d39a46c6b82d50cacc'/>
<id>urn:sha1:bd9f6140e697f52bdc7225d39a46c6b82d50cacc</id>
<content type='text'>
commit dac211ec10d268b9d09000093a9fa2ac1773894f upstream.

ieee80211_rx_mgmt_auth() doesn't handle denied authentication
properly - it authenticates the station and waits for association
(for 5 seconds) instead of failing the authentication.

Fix it by destroying auth_data and bailing out instead.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: fix read outside array bounds</title>
<updated>2012-08-09T15:22:52Z</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@googlemail.com</email>
</author>
<published>2012-07-07T13:07:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8e69df8d54f9458b38aee32a66ac82e3eaf2a6c'/>
<id>urn:sha1:b8e69df8d54f9458b38aee32a66ac82e3eaf2a6c</id>
<content type='text'>
commit 353d09c6ceedc1cb0c54fe5002c0ca80b6ee6e4f upstream.

ieee802_1d_to_ac is defined as a const int[8],
but the tid parameter has a range from 0 to 15.

Signed-off-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: fix crash with single-queue drivers</title>
<updated>2012-08-09T15:22:51Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-07-04T10:49:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f616071b3dc6a09b4b364ba9f020aa744df68b61'/>
<id>urn:sha1:f616071b3dc6a09b4b364ba9f020aa744df68b61</id>
<content type='text'>
commit a6f38ac3cc853189705006cc1e0f17ce8467a1df upstream.

Larry (and some others I think) reported that with
single-queue drivers mac80211 crashes when waking
the queues. This happens because we allocate just
a single queue for each virtual interface in case
the driver doesn't have at least 4 queues, but the
code stopping/waking the virtual interface queues
wasn't taking this into account.

Reported-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tun: fix a crash bug and a memory leak</title>
<updated>2012-08-09T15:22:51Z</updated>
<author>
<name>Mikulas Patocka</name>
<email>mikulas@artax.karlin.mff.cuni.cz</email>
</author>
<published>2012-07-19T06:13:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5d87eafc65b032f71078008f9395503c366330bb'/>
<id>urn:sha1:5d87eafc65b032f71078008f9395503c366330bb</id>
<content type='text'>
commit b09e786bd1dd66418b69348cb110f3a64764626a upstream.

This patch fixes a crash
tun_chr_close -&gt; netdev_run_todo -&gt; tun_free_netdev -&gt; sk_release_kernel -&gt;
sock_release -&gt; iput(SOCK_INODE(sock))
introduced by commit 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d

The problem is that this socket is embedded in struct tun_struct, it has
no inode, iput is called on invalid inode, which modifies invalid memory
and optionally causes a crash.

sock_release also decrements sockets_in_use, this causes a bug that
"sockets: used" field in /proc/*/net/sockstat keeps on decreasing when
creating and closing tun devices.

This patch introduces a flag SOCK_EXTERNALLY_ALLOCATED that instructs
sock_release to not free the inode and not decrement sockets_in_use,
fixing both memory corruption and sockets_in_use underflow.

It should be backported to 3.3 an 3.4 stabke.

Signed-off-by: Mikulas Patocka &lt;mikulas@artax.karlin.mff.cuni.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
