linux-stable.git/net/sunrpc, branch linux-3.19.y

sunrpc: make debugfs file creation failure non-fatal

2015-04-19T08:10:16+00:00

commit f9c72d10d6fbf949558cd088389a42213ed7b12d upstream.

We currently have a problem that SELinux policy is being enforced when
creating debugfs files. If a debugfs file is created as a side effect of
doing some syscall, then that creation can fail if the SELinux policy
for that process prevents it.

This seems wrong. We don't do that for files under /proc, for instance,
so Bruce has proposed a patch to fix that.

While discussing that patch however, Greg K.H. stated:

    "No kernel code should care / fail if a debugfs function fails, so
     please fix up the sunrpc code first."

This patch converts all of the sunrpc debugfs setup code to be void
return functins, and the callers to not look for errors from those
functions.

This should allow rpc_clnt and rpc_xprt creation to work, even if the
kernel fails to create debugfs files for some reason.

Symptoms were failing krb5 mounts on systems using gss-proxy and
selinux.

Fixes: 388f0c776781 "sunrpc: add a debugfs rpc_xprt directory..."
Signed-off-by: Jeff Layton 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock

2015-03-18T13:11:03+00:00

commit 813b00d63f6ca1ed40a2f4f9c034d59bc424025e upstream.

Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock.
xprt_complete_bc_request() should do the same.

Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split . . .")
Signed-off-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

sunrpc: fix braino in ->poll()

2015-03-18T13:11:03+00:00

commit 1711fd9addf214823b993468567cab1f8254fc51 upstream.

POLL_OUT isn't what callers of ->poll() are expecting to see; it's
actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
bit...

Signed-off-by: Al Viro 
Cc: Bruce Fields 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: NULL utsname dereference on NFS umount during namespace cleanup

2015-03-06T22:57:31+00:00

commit 03a9a42a1a7e5b3e7919ddfacc1d1cc81882a955 upstream.

Fix an Oopsable condition when nsm_mon_unmon is called as part of the
namespace cleanup, which now apparently happens after the utsname
has been freed.

Link: http://lkml.kernel.org/r/20150125220604.090121ae@neptune.home
Reported-by: Bruno Prémont 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

rpc: fix xdr_truncate_encode to handle buffer ending on page boundary

2015-01-07T19:03:58+00:00

A struct xdr_stream at a page boundary might point to the end of one
page or the beginning of the next, but xdr_truncate_encode isn't
prepared to handle the former.

This can cause corruption of NFSv4 READDIR replies in the case that a
readdir entry that would have exceeded the client's dircount/maxcount
limit would have ended exactly on a 4k page boundary.  You're more
likely to hit this case on large directories.

Other xdr_truncate_encode callers are probably also affected.

Reported-by: Holger Hoffstätte 
Tested-by: Holger Hoffstätte 
Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode"
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields

sunrpc/cache: convert to use string_escape_str()

2014-12-09T16:30:20+00:00

There is nice kernel helper to escape a given strings by provided rules. Let's
use it instead of custom approach.

Signed-off-by: Andy Shevchenko 
[bfields@redhat.com: fix length calculation]
Signed-off-by: J. Bruce Fields

sunrpc: only call test_bit once in svc_xprt_received

2014-12-09T16:29:14+00:00

...move the WARN_ON_ONCE inside the following if block since they use
the same condition.

Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

sunrpc: add some tracepoints around enqueue and dequeue of svc_xprt

2014-12-09T16:29:14+00:00

These were useful when I was tracking down a race condition between
svc_xprt_do_enqueue and svc_get_next_xprt.

Signed-off-by: Jeff Layton 
Signed-off-by: J. Bruce Fields

sunrpc: convert to lockless lookup of queued server threads

2014-12-09T16:22:22+00:00

Testing has shown that the pool->sp_lock can be a bottleneck on a busy
server. Every time data is received on a socket, the server must take
that lock in order to dequeue a thread from the sp_threads list.

Address this problem by eliminating the sp_threads list (which contains
threads that are currently idle) and replacing it with a RQ_BUSY flag in
svc_rqst. This allows us to walk the sp_all_threads list under the
rcu_read_lock and find a suitable thread for the xprt by doing a
test_and_set_bit.

Note that we do still have a potential atomicity problem however with
this approach.  We don't want svc_xprt_do_enqueue to set the
rqst->rq_xprt pointer unless a test_and_set_bit of RQ_BUSY returned
zero (which indicates that the thread was idle). But, by the time we
check that, the bit could be flipped by a waking thread.

To address this, we acquire a new per-rqst spinlock (rq_lock) and take
that before doing the test_and_set_bit. If that returns false, then we
can set rq_xprt and drop the spinlock. Then, when the thread wakes up,
it must set the bit under the same spinlock and can trust that if it was
already set then the rq_xprt is also properly set.

With this scheme, the case where we have an idle thread no longer needs
to take the highly contended pool->sp_lock at all, and that removes the
bottleneck.

That still leaves one issue: What of the case where we walk the whole
sp_all_threads list and don't find an idle thread? Because the search is
lockess, it's possible for the queueing to race with a thread that is
going to sleep. To address that, we queue the xprt and then search again.

If we find an idle thread at that point, we can't attach the xprt to it
directly since that might race with a different thread waking up and
finding it.  All we can do is wake the idle thread back up and let it
attempt to find the now-queued xprt.

Signed-off-by: Jeff Layton 
Tested-by: Chris Worley 
Signed-off-by: J. Bruce Fields

sunrpc: fix potential races in pool_stats collection

2014-12-09T16:22:22+00:00

In a later patch, we'll be removing some spinlocking around the socket
and thread queueing code in order to fix some contention problems. At
that point, the stats counters will no longer be protected by the
sp_lock.

Change the counters to atomic_long_t fields, except for the
"sockets_queued" counter which will still be manipulated under a
spinlock.

Signed-off-by: Jeff Layton 
Tested-by: Chris Worley 
Signed-off-by: J. Bruce Fields