summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorVivek Goyal <vgoyal@redhat.com>2019-10-15 20:46:22 +0300
committerMiklos Szeredi <mszeredi@redhat.com>2019-10-21 16:57:07 +0300
commit51fecdd2555b3e0e05a78d30093c638d164a32f9 (patch)
tree2760e95ff51c29ca24d74a8ba2c4a32e396621ce /README
parent6c26f71759a6efc04b888dd2c1cc4f1cac38cdf0 (diff)
downloadlinux-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