summaryrefslogtreecommitdiffstats
path: root/net/sched
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2013-10-31 16:14:36 +1100
committerTrond Myklebust <Trond.Myklebust@netapp.com>2013-10-31 09:14:50 -0400
commit93dc41bdc5c853916610576c6b48a1704959c70d (patch)
tree893c971fc8538c8872938c56a442be0abe7db437 /net/sched
parent09c3e54635c85b3da44d3bc156619c1f1af3bb43 (diff)
downloadlinux-93dc41bdc5c853916610576c6b48a1704959c70d.tar.bz2
SUNRPC: close a rare race in xs_tcp_setup_socket.
We have one report of a crash in xs_tcp_setup_socket. The call path to the crash is: xs_tcp_setup_socket -> inet_stream_connect -> lock_sock_nested. The 'sock' passed to that last function is NULL. The only way I can see this happening is a concurrent call to xs_close: xs_close -> xs_reset_transport -> sock_release -> inet_release inet_release sets: sock->sk = NULL; inet_stream_connect calls lock_sock(sock->sk); which gets NULL. All calls to xs_close are protected by XPRT_LOCKED as are most activations of the workqueue which runs xs_tcp_setup_socket. The exception is xs_tcp_schedule_linger_timeout. So presumably the timeout queued by the later fires exactly when some other code runs xs_close(). To protect against this we can move the cancel_delayed_work_sync() call from xs_destory() to xs_close(). As xs_close is never called from the worker scheduled on ->connect_worker, this can never deadlock. Signed-off-by: NeilBrown <neilb@suse.de> [Trond: Make it safe to call cancel_delayed_work_sync() on AF_LOCAL sockets] Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'net/sched')
0 files changed, 0 insertions, 0 deletions