<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/net, branch v3.2.61</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.61</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.2.61'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2014-07-11T12:34:00Z</updated>
<entry>
<title>skbuff: skb_segment: orphan frags before copying</title>
<updated>2014-07-11T12:34:00Z</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2014-03-10T17:28:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=77c01a54cde87eb3bf6685fb44398352f11db3fa'/>
<id>urn:sha1:77c01a54cde87eb3bf6685fb44398352f11db3fa</id>
<content type='text'>
commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f upstream.

skb_segment copies frags around, so we need
to copy them carefully to avoid accessing
user memory after reporting completion to userspace
through a callback.

skb_segment doesn't normally happen on datapath:
TSO needs to be disabled - so disabling zero copy
in this case does not look like a big deal.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[bwh: Backported to 3.2.  As skb_segment() only supports page-frags *or* a
 frag list, there is no need for the additional frag_skb pointer or the
 preparatory renaming.]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>skbuff: export skb_copy_ubufs</title>
<updated>2014-07-11T12:34:00Z</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2012-07-20T09:23:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3ee479fddc52bbcb3b215be56673e9784890b486'/>
<id>urn:sha1:3ee479fddc52bbcb3b215be56673e9784890b486</id>
<content type='text'>
commit dcc0fb782b3a6e2abfeaaeb45dd88ed09596be0f upstream.

Export skb_copy_ubufs so that modules can orphan frags.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.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>sctp: Fix sk_ack_backlog wrap-around problem</title>
<updated>2014-07-11T12:33:57Z</updated>
<author>
<name>Xufeng Zhang</name>
<email>xufeng.zhang@windriver.com</email>
</author>
<published>2014-06-12T02:53:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fe33a3ee987dac85ac24b2d8147d2165051c80d9'/>
<id>urn:sha1:fe33a3ee987dac85ac24b2d8147d2165051c80d9</id>
<content type='text'>
[ Upstream commit d3217b15a19a4779c39b212358a5c71d725822ee ]

Consider the scenario:
For a TCP-style socket, while processing the COOKIE_ECHO chunk in
sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check,
a new association would be created in sctp_unpack_cookie(), but afterwards,
some processing maybe failed, and sctp_association_free() will be called to
free the previously allocated association, in sctp_association_free(),
sk_ack_backlog value is decremented for this socket, since the initial
value for sk_ack_backlog is 0, after the decrement, it will be 65535,
a wrap-around problem happens, and if we want to establish new associations
afterward in the same socket, ABORT would be triggered since sctp deem the
accept queue as full.
Fix this issue by only decrementing sk_ack_backlog for associations in
the endpoint's list.

Fix-suggested-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Signed-off-by: Xufeng Zhang &lt;xufeng.zhang@windriver.com&gt;
Acked-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.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>net: fix inet_getid() and ipv6_select_ident() bugs</title>
<updated>2014-07-11T12:33:57Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-05-29T15:45:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bd89ed9b75277f5a16f91a2331539dd34a8cf852'/>
<id>urn:sha1:bd89ed9b75277f5a16f91a2331539dd34a8cf852</id>
<content type='text'>
[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]

I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer-&gt;ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet &lt;edumazet@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>net: tunnels - enable module autoloading</title>
<updated>2014-07-11T12:33:57Z</updated>
<author>
<name>Tom Gundersen</name>
<email>teg@jklm.no</email>
</author>
<published>2014-05-15T21:21:30Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=30080eb2ea49bff4101b0a3587ae26a590b32c54'/>
<id>urn:sha1:30080eb2ea49bff4101b0a3587ae26a590b32c54</id>
<content type='text'>
[ Upstream commit f98f89a0104454f35a62d681683c844f6dbf4043 ]

Enable the module alias hookup to allow tunnel modules to be autoloaded on demand.

This is in line with how most other netdev kinds work, and will allow userspace
to create tunnels without having CAP_SYS_MODULE.

Signed-off-by: Tom Gundersen &lt;teg@jklm.no&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>Bluetooth: Fix SSP acceptor just-works confirmation without MITM</title>
<updated>2014-07-11T12:33:52Z</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-06-09T10:58:14Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=373d1dfcffc63c68184419264a7eaed422c7958e'/>
<id>urn:sha1:373d1dfcffc63c68184419264a7eaed422c7958e</id>
<content type='text'>
commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream.

From the Bluetooth Core Specification 4.1 page 1958:

"if both devices have set the Authentication_Requirements parameter to
one of the MITM Protection Not Required options, authentication stage 1
shall function as if both devices set their IO capabilities to
DisplayOnly (e.g., Numeric comparison with automatic confirmation on
both devices)"

So far our implementation has done user confirmation for all just-works
cases regardless of the MITM requirements, however following the
specification to the word means that we should not be doing confirmation
when neither side has the MITM flag set.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Tested-by: Szymon Janc &lt;szymon.janc@tieto.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
[bwh: Backported to 3.2: s/conn-&gt;flags/conn-&gt;pend/]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Fix check for connection encryption</title>
<updated>2014-07-11T12:33:52Z</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-06-10T06:54:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d6b05102d11032e0809dabc7231cbcdb6eba4cdc'/>
<id>urn:sha1:d6b05102d11032e0809dabc7231cbcdb6eba4cdc</id>
<content type='text'>
commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream.

The conn-&gt;link_key variable tracks the type of link key in use. It is
set whenever we respond to a link key request as well as when we get a
link key notification event.

These two events do not however always guarantee that encryption is
enabled: getting a link key request and responding to it may only mean
that the remote side has requested authentication but not encryption. On
the other hand, the encrypt change event is a certain guarantee that
encryption is enabled. The real encryption state is already tracked in
the conn-&gt;link_mode variable through the HCI_LM_ENCRYPT bit.

This patch fixes a check for encryption in the hci_conn_auth function to
use the proper conn-&gt;link_mode value and thereby eliminates the chance
of a false positive result.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mac80211: don't check netdev state for debugfs read/write</title>
<updated>2014-07-11T12:33:43Z</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2014-05-26T11:40:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=37543a4eb018efe38c35612b4666d92014812563'/>
<id>urn:sha1:37543a4eb018efe38c35612b4666d92014812563</id>
<content type='text'>
commit 923eaf367206e01f22c97aee22300e332d071916 upstream.

Doing so will lead to an oops for a p2p-dev interface, since it has
no netdev.

Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mac80211: fix IBSS join by initializing last_scan_completed</title>
<updated>2014-07-11T12:33:37Z</updated>
<author>
<name>Krzysztof Hałasa</name>
<email>khalasa@piap.pl</email>
</author>
<published>2014-05-26T12:14:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a398e4147fac72299569e5e0bf4bf3d83b914cb1'/>
<id>urn:sha1:a398e4147fac72299569e5e0bf4bf3d83b914cb1</id>
<content type='text'>
commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream.

Without this fix, freshly rebooted Linux creates a new IBSS
instead of joining an existing one. Only when jiffies counter
overflows after 5 minutes the IBSS can be successfully joined.

Signed-off-by: Krzysztof Hałasa &lt;khalasa@piap.pl&gt;
[edit commit message slightly]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>libceph: fix corruption when using page_count 0 page in rbd</title>
<updated>2014-06-09T12:29:13Z</updated>
<author>
<name>Chunwei Chen</name>
<email>tuxoko@gmail.com</email>
</author>
<published>2014-04-23T04:35:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=512c19f974ef38ace2b8b1f1101dadf36771d29b'/>
<id>urn:sha1:512c19f974ef38ace2b8b1f1101dadf36771d29b</id>
<content type='text'>
commit 178eda29ca721842f2146378e73d43e0044c4166 upstream.

It has been reported that using ZFSonLinux on rbd will result in memory
corruption. The bug report can be found here:

https://github.com/zfsonlinux/spl/issues/241
http://tracker.ceph.com/issues/7790

The reason is that ZFS will send pages with page_count 0 into rbd, which in
turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with
page_count 0, as it will do get_page and put_page, and erroneously free the
page.

This type of issue has been noted before, and handled in iscsi, drbd,
etc. So, rbd should also handle this. This fix address this issue by fall back
to slower sendmsg when page_count 0 detected.

Cc: Sage Weil &lt;sage@inktank.com&gt;
Cc: Yehuda Sadeh &lt;yehuda@inktank.com&gt;
Signed-off-by: Chunwei Chen &lt;tuxoko@gmail.com&gt;
Reviewed-by: Ilya Dryomov &lt;ilya.dryomov@inktank.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
</feed>
