mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-20 17:41:09 +00:00
95503d295a
In the rpc server, When something happens that might be reason to wake up a thread to do something, what we do is - modify xpt_flags, sk_sock->flags, xpt_reserved, or xpt_nr_rqsts to indicate the new situation - call svc_xprt_enqueue() to decide whether to wake up a thread. svc_xprt_enqueue may require multiple conditions to be true before queueing up a thread to handle the xprt. In the SMP case, one of the other CPU's may have set another required condition, and in that case, although both CPUs run svc_xprt_enqueue(), it's possible that neither call sees the writes done by the other CPU in time, and neither one recognizes that all the required conditions have been set. A socket could therefore be ignored indefinitely. Add memory barries to ensure that any svc_xprt_enqueue() call will always see the conditions changed by other CPUs before deciding to ignore a socket. I've never seen this race reported. In the unlikely event it happens, another event will usually come along and the problem will fix itself. So I don't think this is worth backporting to stable. Chuck tried this patch and said "I don't see any performance regressions, but my server has only a single last-level CPU cache." Tested-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> |
||
|---|---|---|
| .. | ||
| auth_gss | ||
| xprtrdma | ||
| addr.c | ||
| auth.c | ||
| auth_null.c | ||
| auth_unix.c | ||
| backchannel_rqst.c | ||
| cache.c | ||
| clnt.c | ||
| debugfs.c | ||
| Kconfig | ||
| Makefile | ||
| netns.h | ||
| rpc_pipe.c | ||
| rpcb_clnt.c | ||
| sched.c | ||
| socklib.c | ||
| stats.c | ||
| sunrpc.h | ||
| sunrpc_syms.c | ||
| svc.c | ||
| svc_xprt.c | ||
| svcauth.c | ||
| svcauth_unix.c | ||
| svcsock.c | ||
| sysctl.c | ||
| timer.c | ||
| xdr.c | ||
| xprt.c | ||
| xprtmultipath.c | ||
| xprtsock.c | ||