<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net/core, branch v3.10.2</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net/core?h=v3.10.2</id>
<link rel='self' href='https://git.amat.us/linux/atom/net/core?h=v3.10.2'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-06-26T20:42:54Z</updated>
<entry>
<title>net: fix kernel deadlock with interface rename and netdev name retrieval.</title>
<updated>2013-06-26T20:42:54Z</updated>
<author>
<name>Nicolas Schichan</name>
<email>nschichan@freebox.fr</email>
</author>
<published>2013-06-26T15:23:42Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5dbe7c178d3f0a4634f088d9e729f1909b9ddcd1'/>
<id>urn:sha1:5dbe7c178d3f0a4634f088d9e729f1909b9ddcd1</id>
<content type='text'>
When the kernel (compiled with CONFIG_PREEMPT=n) is performing the
rename of a network interface, it can end up waiting for a workqueue
to complete. If userland is able to invoke a SIOCGIFNAME ioctl or a
SO_BINDTODEVICE getsockopt in between, the kernel will deadlock due to
the fact that read_secklock_begin() will spin forever waiting for the
writer process (the one doing the interface rename) to update the
devnet_rename_seq sequence.

This patch fixes the problem by adding a helper (netdev_get_name())
and using it in the code handling the SIOCGIFNAME ioctl and
SO_BINDTODEVICE setsockopt.

The netdev_get_name() helper uses raw_seqcount_begin() to avoid
spinning forever, waiting for devnet_rename_seq-&gt;sequence to become
even. cond_resched() is used in the contended case, before retrying
the access to give the writer process a chance to finish.

The use of raw_seqcount_begin() will incur some unneeded work in the
reader process in the contended case, but this is better than
deadlocking the system.

Signed-off-by: Nicolas Schichan &lt;nschichan@freebox.fr&gt;
Acked-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gre: fix a possible skb leak</title>
<updated>2013-06-25T23:07:44Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2013-06-24T13:26:00Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bd8a7036c06cf15779b31a5397d4afcb12be81ea'/>
<id>urn:sha1:bd8a7036c06cf15779b31a5397d4afcb12be81ea</id>
<content type='text'>
commit 68c331631143 ("v4 GRE: Add TCP segmentation offload for GRE")
added a possible skb leak, because it frees only the head of segment
list, in case a skb_linearize() call fails.

This patch adds a kfree_skb_list() helper to fix the bug.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Pravin B Shelar &lt;pshelar@nicira.com&gt;
Cc: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>vlan: restore ethtool ABI to control VLAN hardware acceleration</title>
<updated>2013-06-18T00:09:35Z</updated>
<author>
<name>Fernando Luis Vazquez Cao</name>
<email>fernando_b1@lab.ntt.co.jp</email>
</author>
<published>2013-06-17T02:28:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=788dfcacacfbdd51f9c92065bd8e136686f07a29'/>
<id>urn:sha1:788dfcacacfbdd51f9c92065bd8e136686f07a29</id>
<content type='text'>
As part of the push to add 802.1ad server provider tagging support to the
kernel the VLAN features flags were renamed. Unfortunately the kernel name
for the VLAN hardware acceleration features that the kernel shows user space
was included in the rename, which broke ethtool (txvlan and rxvlan options
do not work). This patch restores the original names, i.e. the original ABI.
If we wanted to make clear to users that we are refering to CTAGs we can
always change ethtool's short_name and long_name for these features (for
example something along the lines of txvlan -&gt; txvlan-ctag, tx-vlan-offload -&gt;
tx-vlan-ctag-offload).

Cc: Patrick McHardy &lt;kaber@trash.net&gt;
Cc: David S. Miller &lt;davem@davemloft.net&gt;
Cc: netdev@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao &lt;fernando@oss.ntt.co.jp&gt;
Reviewed-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sock_diag: fix filter code sent to userspace</title>
<updated>2013-06-11T05:23:32Z</updated>
<author>
<name>Nicolas Dichtel</name>
<email>nicolas.dichtel@6wind.com</email>
</author>
<published>2013-06-05T13:30:55Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ed13998c319b050fc9abdb73915859dfdbe1fb38'/>
<id>urn:sha1:ed13998c319b050fc9abdb73915859dfdbe1fb38</id>
<content type='text'>
Filters need to be translated to real BPF code for userland, like SO_GETFILTER.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: fix sk_buff head without data area</title>
<updated>2013-06-05T00:26:49Z</updated>
<author>
<name>Pablo Neira</name>
<email>pablo@netfilter.org</email>
</author>
<published>2013-06-03T09:28:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5e71d9d77c07fa7d4c42287a177f7b738d0cd4b9'/>
<id>urn:sha1:5e71d9d77c07fa7d4c42287a177f7b738d0cd4b9</id>
<content type='text'>
Eric Dumazet spotted that we have to check skb-&gt;head instead
of skb-&gt;data as skb-&gt;head points to the beginning of the
data area of the skbuff. Similarly, we have to initialize the
skb-&gt;head pointer, not skb-&gt;data in __alloc_skb_head.

After this fix, netlink crashes in the release path of the
sk_buff, so let's fix that as well.

This bug was introduced in (0ebd0ac net: add function to
allocate sk_buff head without data area).

Reported-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: Pablo Neira Ayuso &lt;pablo@netfilter.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/core: dev_mc_sync_multiple calls wrong helper</title>
<updated>2013-05-31T23:56:56Z</updated>
<author>
<name>Jay Vosburgh</name>
<email>fubar@us.ibm.com</email>
</author>
<published>2013-05-31T11:57:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b190a50875b95e58ebe2b00ed3bf7f1d44961471'/>
<id>urn:sha1:b190a50875b95e58ebe2b00ed3bf7f1d44961471</id>
<content type='text'>
The dev_mc_sync_multiple function is currently calling
__hw_addr_sync, and not __hw_addr_sync_multiple.  This will result in
addresses only being synced to the first device from the set.

	Corrected by calling the _multiple variant.

Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Reviewed-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Tested-by: Shawn Bohrer &lt;sbohrer@rgmadvisors.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/core: __hw_addr_sync_one / _multiple broken</title>
<updated>2013-05-31T23:56:56Z</updated>
<author>
<name>Jay Vosburgh</name>
<email>fubar@us.ibm.com</email>
</author>
<published>2013-05-31T11:57:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=29ca2f8fcc721517b83d0a560c47cee2dde827a6'/>
<id>urn:sha1:29ca2f8fcc721517b83d0a560c47cee2dde827a6</id>
<content type='text'>
Currently, __hw_addr_sync_one is called in a loop by
__hw_addr_sync_multiple to sync each of a "from" device's hw addresses
to a "to" device.  __hw_addr_sync_one calls __hw_addr_add_ex to attempt
to add each address.  __hw_addr_add_ex is called with global=false, and
sync=true.

	__hw_addr_add_ex checks to see if the new address matches an
address already on the list.  If so, it tests global and sync.  In this
case, sync=true, and it then checks if the address is already synced,
and if so, returns 0.

	This 0 return causes __hw_addr_sync_one to increment the sync_cnt
and refcount for the "from" list's address entry, even though the address
is already synced and has a reference and sync_cnt.  This will cause
the sync_cnt and refcount to increment without bound every time an
addresses is added to the "from" device and synced to the "to" device.

	The fix here has two parts:

	First, when __hw_addr_add_ex finds the address already exists
and is synced, return -EEXIST instead of 0.

	Second, __hw_addr_sync_one checks the error return for -EEXIST,
and if so, it (a) does not add a refcount/sync_cnt, and (b) returns 0
itself so that __hw_addr_sync_multiple will not return an error.

Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Reviewed-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Tested-by: Shawn Bohrer &lt;sbohrer@rgmadvisors.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/core: __hw_addr_unsync_one "from" address not marked synced</title>
<updated>2013-05-31T23:56:56Z</updated>
<author>
<name>Jay Vosburgh</name>
<email>fubar@us.ibm.com</email>
</author>
<published>2013-05-31T11:57:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=60ba834c2fb65f2fafee47e03c258fac579d0591'/>
<id>urn:sha1:60ba834c2fb65f2fafee47e03c258fac579d0591</id>
<content type='text'>
When an address is added to a subordinate interface (the "to"
list), the address entry in the "from" list is not marked "synced" as
the entry added to the "to" list is.

	When performing the unsync operation (e.g., dev_mc_unsync),
__hw_addr_unsync_one calls __hw_addr_del_entry with the "synced"
parameter set to true for the case when the address reference is being
released from the "from" list.  This causes a test inside to fail,
with the result being that the reference count on the "from" address
is not properly decremeted and the address on the "from" list will
never be freed.

	Correct this by having __hw_addr_unsync_one call the
__hw_addr_del_entry function with the "sync" flag set to false for the
"remove from the from list" case.

Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Reviewed-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Tested-by: Shawn Bohrer &lt;sbohrer@rgmadvisors.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/core: __hw_addr_create_ex does not initialize sync_cnt</title>
<updated>2013-05-31T23:56:56Z</updated>
<author>
<name>Jay Vosburgh</name>
<email>fubar@us.ibm.com</email>
</author>
<published>2013-05-31T11:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9747ba6636be8a7e8ba83a1fb231d061ca318e4f'/>
<id>urn:sha1:9747ba6636be8a7e8ba83a1fb231d061ca318e4f</id>
<content type='text'>
The sync_cnt field is not being initialized, which can result
in arbitrary values in the field.  Fixed by initializing it to zero.

Signed-off-by: Jay Vosburgh &lt;fubar@us.ibm.com&gt;
Reviewed-by: Vlad Yasevich &lt;vyasevic@redhat.com&gt;
Tested-by: Shawn Bohrer &lt;sbohrer@rgmadvisors.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net/core/sock.c: add missing VSOCK string in af_family_*_key_strings</title>
<updated>2013-05-29T06:58:49Z</updated>
<author>
<name>Federico Vaga</name>
<email>federico.vaga@gmail.com</email>
</author>
<published>2013-05-28T05:02:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=456db6a4d495f40777da6f1f32f62f13026f52db'/>
<id>urn:sha1:456db6a4d495f40777da6f1f32f62f13026f52db</id>
<content type='text'>
The three arrays of strings: af_family_key_strings,
af_family_slock_key_strings and af_family_clock_key_strings have not
VSOCK's string

Signed-off-by: Federico Vaga &lt;federico.vaga@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
