<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.2.41</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.2.41</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.2.41'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-03-20T15:03:39Z</updated>
<entry>
<title>batman-adv: Only write requested number of byte to user buffer</title>
<updated>2013-03-20T15:03:39Z</updated>
<author>
<name>Sven Eckelmann</name>
<email>sven@narfation.org</email>
</author>
<published>2011-12-10T14:28:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f3fa0df5ebda0dc467920f9e855a7b9481b3dafd'/>
<id>urn:sha1:f3fa0df5ebda0dc467920f9e855a7b9481b3dafd</id>
<content type='text'>
commit b5a1eeef04cc7859f34dec9b72ea1b28e4aba07c upstream.

Don't write more than the requested number of bytes of an batman-adv icmp
packet to the userspace buffer. Otherwise unrelated userspace memory might get
overridden by the kernel.

Signed-off-by: Sven Eckelmann &lt;sven@narfation.org&gt;
Signed-off-by: Marek Lindner &lt;lindner_marek@yahoo.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>batman-adv: bat_socket_read missing checks</title>
<updated>2013-03-20T15:03:39Z</updated>
<author>
<name>Paul Kot</name>
<email>pawlkt@gmail.com</email>
</author>
<published>2011-12-10T14:28:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=83257435faca1827b17e7e6e1766f9c0c216595d'/>
<id>urn:sha1:83257435faca1827b17e7e6e1766f9c0c216595d</id>
<content type='text'>
commit c00b6856fc642b234895cfabd15b289e76726430 upstream.

Writing a icmp_packet_rr and then reading icmp_packet can lead to kernel
memory corruption, if __user *buf is just below TASK_SIZE.

Signed-off-by: Paul Kot &lt;pawlkt@gmail.com&gt;
[sven@narfation.org: made it checkpatch clean]
Signed-off-by: Sven Eckelmann &lt;sven@narfation.org&gt;
Signed-off-by: Marek Lindner &lt;lindner_marek@yahoo.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>decnet: Fix disappearing sysctl entries</title>
<updated>2013-03-20T15:03:28Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-03-12T00:41:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3125bdd601790d03f36343d9d0941c5f94244f27'/>
<id>urn:sha1:3125bdd601790d03f36343d9d0941c5f94244f27</id>
<content type='text'>
When decnet is built as a module a simple:
echo 0.0 &gt;/proc/sys/net/decnet/node_address

results in most of the sysctl entries under /proc/sys/net/decnet and
/proc/sys/net/decnet/conf disappearing.

For more details see http://www.spinics.net/lists/netdev/msg226123.html.

This change applies the same workaround used in
net/core/sysctl_net_core.c and net/ipv6/sysctl_net_ipv6.c of creating
a skeleton of decnet sysctl entries before doing anything else.

The problem first appeared in kernel 2.6.27.  The later rewrite of
sysctl in kernel 3.4 restored the previous behavior and eliminated the
need for this workaround.

This patch was heavily inspired by a similar but more complex patch by
Larry Baker.

Reported-by: Larry Baker &lt;baker@usgs.gov&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>SUNRPC: Don't start the retransmission timer when out of socket space</title>
<updated>2013-03-20T15:03:16Z</updated>
<author>
<name>Trond Myklebust</name>
<email>Trond.Myklebust@netapp.com</email>
</author>
<published>2013-02-22T19:57:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=8c5e63a26e6b92c4cb171273beadc02a989f4939'/>
<id>urn:sha1:8c5e63a26e6b92c4cb171273beadc02a989f4939</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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ipv6: use a stronger hash for tcp</title>
<updated>2013-03-06T03:24:21Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-02-21T12:18:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0fd0ff7e1fcc4b4bc5d17ab1d200f23dea7c681d'/>
<id>urn:sha1:0fd0ff7e1fcc4b4bc5d17ab1d200f23dea7c681d</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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ipv4: fix a bug in ping_err().</title>
<updated>2013-03-06T03:24:20Z</updated>
<author>
<name>Li Wei</name>
<email>lw@cn.fujitsu.com</email>
</author>
<published>2013-02-21T00:09:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=52430c06469c05c36dd688c8daff25e5bcfde8e9'/>
<id>urn:sha1:52430c06469c05c36dd688c8daff25e5bcfde8e9</id>
<content type='text'>
[ Upstream commit b531ed61a2a2a77eeb2f7c88b49aa5ec7d9880d8 ]

We should get 'type' and 'code' from the outer ICMP header.

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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>bridge: set priority of STP packets</title>
<updated>2013-03-06T03:24:19Z</updated>
<author>
<name>Stephen Hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2013-02-11T08:22:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1642974c7f646c8a32bc7a15d37f4e14ceead334'/>
<id>urn:sha1:1642974c7f646c8a32bc7a15d37f4e14ceead334</id>
<content type='text'>
[ Upstream commit 547b4e718115eea74087e28d7fa70aec619200db ]

Spanning Tree Protocol packets should have always been marked as
control packets, this causes them to get queued in the high prirority
FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge
gets overloaded and can't communicate. This is a long-standing bug back
to the first versions of Linux bridge.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>svcrpc: make svc_age_temp_xprts enqueue under sv_lock</title>
<updated>2013-03-06T03:24:01Z</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2013-02-10T16:33:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a60210baeedfc036f19fcbf58fe9c82d26ea12a5'/>
<id>urn:sha1:a60210baeedfc036f19fcbf58fe9c82d26ea12a5</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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>bridge: Pull ip header into skb-&gt;data before looking into ip header.</title>
<updated>2013-02-20T03:15:39Z</updated>
<author>
<name>Sarveshwar Bandi</name>
<email>sarveshwar.bandi@emulex.com</email>
</author>
<published>2012-10-10T01:15:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=335c3391c34f5a607ca63d606f9b2d9f747bab4a'/>
<id>urn:sha1:335c3391c34f5a607ca63d606f9b2d9f747bab4a</id>
<content type='text'>
[ Upstream commit 6caab7b0544e83e6c160b5e80f5a4a7dd69545c7 ]

If lower layer driver leaves the ip header in the skb fragment, it needs to
be first pulled into skb-&gt;data before inspecting ip header length or ip version
number.

Signed-off-by: Sarveshwar Bandi &lt;sarveshwar.bandi@emulex.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>tcp: fix for zero packets_in_flight was too broad</title>
<updated>2013-02-20T03:15:38Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@helsinki.fi</email>
</author>
<published>2013-02-04T02:14:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4670ea19f63e7db7ca352e68e120e82e3c135fbb'/>
<id>urn:sha1:4670ea19f63e7db7ca352e68e120e82e3c135fbb</id>
<content type='text'>
[ Upstream commit 6731d2095bd4aef18027c72ef845ab1087c3ba63 ]

There are transients during normal FRTO procedure during which
the packets_in_flight can go to zero between write_queue state
updates and firing the resulting segments out. As FRTO processing
occurs during that window the check must be more precise to
not match "spuriously" :-). More specificly, e.g., when
packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic
branch that set cwnd into zero would not be taken and new segments
might be sent out later.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Tested-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
</feed>
