<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net, branch v4.7.4</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.7.4</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.7.4'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2016-09-15T06:20:29+00:00</updated>
<entry>
<title>xprtrdma: Create common scatterlist fields in rpcrdma_mw</title>
<updated>2016-09-15T06:20:29+00:00</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2016-06-29T17:52:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ee6a072a35bfd25a3bf0a2325fe9d6242f98753'/>
<id>urn:sha1:9ee6a072a35bfd25a3bf0a2325fe9d6242f98753</id>
<content type='text'>
commit 564471d2f2f1ddaf02119b8759813666db93abba upstream.

Clean up: FMR is about to replace the rpcrdma_map_one code with
scatterlists. Move the scatterlist fields out of the FRWR-specific
union and into the generic part of rpcrdma_mw.

One minor change: -EIO is now returned if FRWR registration fails.
The RPC is terminated immediately, since the problem is likely due
to a software bug, thus retrying likely won't help.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Tested-by: Steve Wise &lt;swise@opengridcomputing.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: Use ns_capable_noaudit() when determining net sysctl permissions</title>
<updated>2016-09-15T06:20:25+00:00</updated>
<author>
<name>Tyler Hicks</name>
<email>tyhicks@canonical.com</email>
</author>
<published>2016-06-03T04:43:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc08184d38909a70596ccdf6acc49b4f7723266c'/>
<id>urn:sha1:fc08184d38909a70596ccdf6acc49b4f7723266c</id>
<content type='text'>
commit d6e0d306449bcb5fa3c80e7a3edf11d45abf9ae9 upstream.

The capability check should not be audited since it is only being used
to determine the inode permissions. A failed check does not indicate a
violation of security policy but, when an LSM is enabled, a denial audit
message was being generated.

The denial audit message caused confusion for some application authors
because root-running Go applications always triggered the denial. To
prevent this confusion, the capability check in net_ctl_permissions() is
switched to the noaudit variant.

BugLink: https://launchpad.net/bugs/1465724

Signed-off-by: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Acked-by: Serge E. Hallyn &lt;serge.hallyn@ubuntu.com&gt;
Signed-off-by: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SUNRPC: Fix infinite looping in rpc_clnt_iterate_for_each_xprt</title>
<updated>2016-09-07T06:34:56+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@primarydata.com</email>
</author>
<published>2016-07-16T15:47:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6b553b7ac74ddc1450e8b0a52dfdcfab9129d4c2'/>
<id>urn:sha1:6b553b7ac74ddc1450e8b0a52dfdcfab9129d4c2</id>
<content type='text'>
commit bdc54d8e3cb4a41dddcabfd86d9eb3aa5f622b75 upstream.

If there were less than 2 entries in the multipath list, then
xprt_iter_next_entry_multiple() would never advance beyond the
first entry, which is correct for round robin behaviour, but not
for the list iteration.

The end result would be infinite looping in rpc_clnt_iterate_for_each_xprt()
as we would never see the xprt == NULL condition fulfilled.

Reported-by: Oleg Drokin &lt;green@linuxhacker.ru&gt;
Fixes: 80b14d5e61ca ("SUNRPC: Add a structure to track multiple transports")
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Cc: Jason L Tibbitts III &lt;tibbs@math.uh.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: fix purging multicast PS buffer queue</title>
<updated>2016-09-07T06:34:49+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2016-08-02T09:13:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07b081a8f7237810859edb732e93d88f097d1dd3'/>
<id>urn:sha1:07b081a8f7237810859edb732e93d88f097d1dd3</id>
<content type='text'>
commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 upstream.

The code currently assumes that buffered multicast PS frames don't have
a pending ACK frame for tx status reporting.
However, hostapd sends a broadcast deauth frame on teardown for which tx
status is requested. This can lead to the "Have pending ack frames"
warning on module reload.
Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&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>SUNRPC: allow for upcalls for same uid but different gss service</title>
<updated>2016-09-07T06:34:43+00:00</updated>
<author>
<name>Olga Kornievskaia</name>
<email>kolga@netapp.com</email>
</author>
<published>2016-08-04T00:19:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4fd2aa1137cecde98b0895775ff8472bc5e08ef4'/>
<id>urn:sha1:4fd2aa1137cecde98b0895775ff8472bc5e08ef4</id>
<content type='text'>
commit 9130b8dbc6ac20f2dc5846e1647f5b60eafab6e3 upstream.

It's possible to have simultaneous upcalls for the same UIDs but
different GSS service. In that case, we need to allow for the
upcall to gssd to proceed so that not the same context is used
by two different GSS services. Some servers lock the use of context
to the GSS service.

Signed-off-by: Olga Kornievskaia &lt;kolga@netapp.com&gt;
Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>SUNRPC: Handle EADDRNOTAVAIL on connection failures</title>
<updated>2016-09-07T06:34:43+00:00</updated>
<author>
<name>Trond Myklebust</name>
<email>trond.myklebust@primarydata.com</email>
</author>
<published>2016-08-01T17:36:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=071f3ed4bd40e7d12130fa3e0ecf2e3acea55ce5'/>
<id>urn:sha1:071f3ed4bd40e7d12130fa3e0ecf2e3acea55ce5</id>
<content type='text'>
commit 1f4c17a03ba7f430d63dba8c8e08ff1e2712581d upstream.

If the connect attempt immediately fails with an EADDRNOTAVAIL error, then
that means our choice of source port number was bad.
This error is expected when we set the SO_REUSEPORT socket option and we
have 2 sockets sharing the same source and destination address and port
combinations.

Signed-off-by: Trond Myklebust &lt;trond.myklebust@primarydata.com&gt;
Fixes: 402e23b4ed9ed ("SUNRPC: Fix stupid typo in xs_sock_set_reuseport")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>netlabel: add address family checks to netlbl_{sock,req}_delattr()</title>
<updated>2016-08-20T16:10:58+00:00</updated>
<author>
<name>Paul Moore</name>
<email>paul@paul-moore.com</email>
</author>
<published>2016-06-06T19:17:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6520eadab50ec5def9a41c3ae11598ff16485f93'/>
<id>urn:sha1:6520eadab50ec5def9a41c3ae11598ff16485f93</id>
<content type='text'>
commit 0e0e36774081534783aa8eeb9f6fbddf98d3c061 upstream.

It seems risky to always rely on the caller to ensure the socket's
address family is correct before passing it to the NetLabel kAPI,
especially since we see at least one LSM which didn't. Add address
family checks to the *_delattr() functions to help prevent future
problems.

Reported-by: Maninder Singh &lt;maninder1.s@samsung.com&gt;
Signed-off-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Bluetooth: Fix l2cap_sock_setsockopt() with optname BT_RCVMTU</title>
<updated>2016-08-20T16:10:54+00:00</updated>
<author>
<name>Amadeusz Sławiński</name>
<email>amadeusz.slawinski@tieto.com</email>
</author>
<published>2016-07-14T08:50:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=34fc69f9aa9893b98b129d6a7ac12a667a430bd4'/>
<id>urn:sha1:34fc69f9aa9893b98b129d6a7ac12a667a430bd4</id>
<content type='text'>
commit 23bc6ab0a0912146fd674a0becc758c3162baabc upstream.

When we retrieve imtu value from userspace we should use 16 bit pointer
cast instead of 32 as it's defined that way in headers. Fixes setsockopt
calls on big-endian platforms.

Signed-off-by: Amadeusz Sławiński &lt;amadeusz.slawinski@tieto.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tcp: consider recv buf for the initial window scale</title>
<updated>2016-08-16T07:34:58+00:00</updated>
<author>
<name>Soheil Hassas Yeganeh</name>
<email>soheil@google.com</email>
</author>
<published>2016-07-29T13:34:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=89c2f98f31c17a81ed736b101e10b2472777e307'/>
<id>urn:sha1:89c2f98f31c17a81ed736b101e10b2472777e307</id>
<content type='text'>
[ Upstream commit f626300a3e776ccc9671b0dd94698fb3aa315966 ]

tcp_select_initial_window() intends to advertise a window
scaling for the maximum possible window size. To do so,
it considers the maximum of net.ipv4.tcp_rmem[2] and
net.core.rmem_max as the only possible upper-bounds.
However, users with CAP_NET_ADMIN can use SO_RCVBUFFORCE
to set the socket's receive buffer size to values
larger than net.ipv4.tcp_rmem[2] and net.core.rmem_max.
Thus, SO_RCVBUFFORCE is effectively ignored by
tcp_select_initial_window().

To fix this, consider the maximum of net.ipv4.tcp_rmem[2],
net.core.rmem_max and socket's initial buffer space.

Fixes: b0573dea1fb3 ("[NET]: Introduce SO_{SND,RCV}BUFFORCE socket options")
Signed-off-by: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Suggested-by: Neal Cardwell &lt;ncardwell@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net/sctp: terminate rhashtable walk correctly</title>
<updated>2016-08-16T07:34:58+00:00</updated>
<author>
<name>Vegard Nossum</name>
<email>vegard.nossum@oracle.com</email>
</author>
<published>2016-07-23T07:42:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=77719251041381423bf6fb4ae9d529e2a42adb55'/>
<id>urn:sha1:77719251041381423bf6fb4ae9d529e2a42adb55</id>
<content type='text'>
[ Upstream commit 5fc382d87517707ad77ea4c9c12e2a3fde2c838a ]

I was seeing a lot of these:

    BUG: sleeping function called from invalid context at mm/slab.h:388
    in_atomic(): 0, irqs_disabled(): 0, pid: 14971, name: trinity-c2
    Preemption disabled at:[&lt;ffffffff819bcd46&gt;] rhashtable_walk_start+0x46/0x150

     [&lt;ffffffff81149abb&gt;] preempt_count_add+0x1fb/0x280
     [&lt;ffffffff83295722&gt;] _raw_spin_lock+0x12/0x40
     [&lt;ffffffff811aac87&gt;] console_unlock+0x2f7/0x930
     [&lt;ffffffff811ab5bb&gt;] vprintk_emit+0x2fb/0x520
     [&lt;ffffffff811aba6a&gt;] vprintk_default+0x1a/0x20
     [&lt;ffffffff812c171a&gt;] printk+0x94/0xb0
     [&lt;ffffffff811d6ed0&gt;] print_stack_trace+0xe0/0x170
     [&lt;ffffffff8115835e&gt;] ___might_sleep+0x3be/0x460
     [&lt;ffffffff81158490&gt;] __might_sleep+0x90/0x1a0
     [&lt;ffffffff8139b823&gt;] kmem_cache_alloc+0x153/0x1e0
     [&lt;ffffffff819bca1e&gt;] rhashtable_walk_init+0xfe/0x2d0
     [&lt;ffffffff82ec64de&gt;] sctp_transport_walk_start+0x1e/0x60
     [&lt;ffffffff82edd8ad&gt;] sctp_transport_seq_start+0x4d/0x150
     [&lt;ffffffff8143a82b&gt;] seq_read+0x27b/0x1180
     [&lt;ffffffff814f97fc&gt;] proc_reg_read+0xbc/0x180
     [&lt;ffffffff813d471b&gt;] __vfs_read+0xdb/0x610
     [&lt;ffffffff813d4d3a&gt;] vfs_read+0xea/0x2d0
     [&lt;ffffffff813d615b&gt;] SyS_pread64+0x11b/0x150
     [&lt;ffffffff8100334c&gt;] do_syscall_64+0x19c/0x410
     [&lt;ffffffff832960a5&gt;] return_from_SYSCALL_64+0x0/0x6a
     [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Apparently we always need to call rhashtable_walk_stop(), even when
rhashtable_walk_start() fails:

 * rhashtable_walk_start - Start a hash table walk
 * @iter:       Hash table iterator
 *
 * Start a hash table walk.  Note that we take the RCU lock in all
 * cases including when we return an error.  So you must always call
 * rhashtable_walk_stop to clean up.

otherwise we never call rcu_read_unlock() and we get the splat above.

Fixes: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: 53fa1036 ("sctp: fix some rhashtable functions using in sctp proc/diag")
See-also: f2dba9c6 ("rhashtable: Introduce rhashtable_walk_*")
Cc: Xin Long &lt;lucien.xin@gmail.com&gt;
Cc: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Vegard Nossum &lt;vegard.nossum@oracle.com&gt;
Acked-by: Marcelo Ricardo Leitner &lt;marcelo.leitner@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>
</feed>
