diff options
author | NeilBrown <neilb@suse.de> | 2013-10-31 05:14:36 (GMT) |
---|---|---|
committer | Jiri Slaby <jslaby@suse.cz> | 2014-03-12 12:25:40 (GMT) |
commit | 6456bd97dfc0bf51439de35955628e89dd8bccd7 (patch) | |
tree | 11983e4ec55be83275ea56ad43d9fa92195c0e06 /arch/x86/kernel/ptrace.c | |
parent | 4aef0b11ba4fa4c2cd115c312dd9f0b64cad1bf1 (diff) | |
download | linux-fsl-qoriq-6456bd97dfc0bf51439de35955628e89dd8bccd7.tar.xz |
SUNRPC: close a rare race in xs_tcp_setup_socket.
commit 93dc41bdc5c853916610576c6b48a1704959c70d upstream.
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>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Diffstat (limited to 'arch/x86/kernel/ptrace.c')
0 files changed, 0 insertions, 0 deletions