kernel/linux.git/include/trace/events/sunrpc.h, branch v4.4.193

SUNRPC: Fix tracepoint storage issues with svc_recv and svc_rqst_status

2017-11-30T08:37:23+00:00

commit e9d4bf219c83d09579bc62512fea2ca10f025d93 upstream. There is no guarantee that either the request or the svc_xprt exist by the time we get round to printing the trace message. Signed-off-by: Trond Myklebust Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

SUNRPC: Don't allocate a full sockaddr_storage for tracing

2016-08-20T16:09:26+00:00

commit db1bb44c4c7e8d49ed674dc59e5222d99c698088 upstream. We're always tracing IPv4 or IPv6 addresses, so we can save a lot of space on the ringbuffer by allocating the correct sockaddr size. Signed-off-by: Trond Myklebust Fixes: 83a712e0afef "sunrpc: add some tracepoints around ..." Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

net: sunrpc: fix tracepoint Warning: unknown op '->'

2015-08-31T20:32:15+00:00

`perf stat -e sunrpc:svc_xprt_do_enqueue true` results in Warning: unknown op '->' Warning: [sunrpc:svc_xprt_do_enqueue] unknown op '->' Similar warning for svc_handle_xprt as well. Actually TP_printk() should never dereference an address saved in the ring buffer that points somewhere in the kernel. There's no guarantee that that object still exists (with the exception of static strings). Therefore change all the arguments for TP_printk(), so that it references values existing in the ring buffer only. While doing that, also fix another possible bug when argument xprt could be NULL and TP_fast_assign() tries to access it's elements. Signed-off-by: Pratyush Anand Reviewed-by: Jeff Layton Acked-by: Steven Rostedt Cc: stable@vger.kernel.org Fixes: 83a712e0afef "sunrpc: add some tracepoints around ..." Signed-off-by: J. Bruce Fields

SUNRPC: Export enums in tracepoints to user space

2015-04-08T13:41:08+00:00

The enums used in the tracepoints for __print_symbolic() have their names shown in the tracepoint format files. User space tools do not know how to convert those names into their values to be able to convert the binary data. Use TRACE_DEFINE_ENUM() to export the enum names to their values for userspace to do the parsing correctly. Link: http://lkml.kernel.org/r/20150403013802.220157513@goodmis.org Acked-by: Trond Myklebust Reviewed-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Steven Rostedt

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: add a rcu_head to svc_rqst and use kfree_rcu to free it

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

...also make the manipulation of sp_all_threads list use RCU-friendly functions. Signed-off-by: Jeff Layton Tested-by: Chris Worley Signed-off-by: J. Bruce Fields

sunrpc: move rq_splice_ok flag into rq_flags

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

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

sunrpc: move rq_dropme flag into rq_flags

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

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

sunrpc: move rq_usedeferral flag to rq_flags

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

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