diff options
author | Vivek Goyal <vgoyal@redhat.com> | 2019-10-15 20:46:22 +0300 |
---|---|---|
committer | Miklos Szeredi <mszeredi@redhat.com> | 2019-10-21 16:57:07 +0300 |
commit | 51fecdd2555b3e0e05a78d30093c638d164a32f9 (patch) | |
tree | 2760e95ff51c29ca24d74a8ba2c4a32e396621ce /README | |
parent | 6c26f71759a6efc04b888dd2c1cc4f1cac38cdf0 (diff) | |
download | linux-51fecdd2555b3e0e05a78d30093c638d164a32f9.tar.xz |
virtiofs: Do not end request in submission context
Submission context can hold some locks which end request code tries to hold
again and deadlock can occur. For example, fc->bg_lock. If a background
request is being submitted, it might hold fc->bg_lock and if we could not
submit request (because device went away) and tried to end request, then
deadlock happens. During testing, I also got a warning from deadlock
detection code.
So put requests on a list and end requests from a worker thread.
I got following warning from deadlock detector.
[ 603.137138] WARNING: possible recursive locking detected
[ 603.137142] --------------------------------------------
[ 603.137144] blogbench/2036 is trying to acquire lock:
[ 603.137149] 00000000f0f51107 (&(&fc->bg_lock)->rlock){+.+.}, at: fuse_request_end+0xdf/0x1c0 [fuse]
[ 603.140701]
[ 603.140701] but task is already holding lock:
[ 603.140703] 00000000f0f51107 (&(&fc->bg_lock)->rlock){+.+.}, at: fuse_simple_background+0x92/0x1d0 [fuse]
[ 603.140713]
[ 603.140713] other info that might help us debug this:
[ 603.140714] Possible unsafe locking scenario:
[ 603.140714]
[ 603.140715] CPU0
[ 603.140716] ----
[ 603.140716] lock(&(&fc->bg_lock)->rlock);
[ 603.140718] lock(&(&fc->bg_lock)->rlock);
[ 603.140719]
[ 603.140719] *** DEADLOCK ***
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions