summary refs log tree commit diff
path: root/tools/scripts
diff options
context:
space:
mode:
authorVivek Goyal <vgoyal@redhat.com>2019-10-15 13:46:22 -0400
committerMiklos Szeredi <mszeredi@redhat.com>2019-10-21 15:57:07 +0200
commit51fecdd2555b3e0e05a78d30093c638d164a32f9 (patch)
tree2760e95ff51c29ca24d74a8ba2c4a32e396621ce /tools/scripts
parent6c26f71759a6efc04b888dd2c1cc4f1cac38cdf0 (diff)
downloadlinux-51fecdd2555b3e0e05a78d30093c638d164a32f9.tar.gz
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 'tools/scripts')
0 files changed, 0 insertions, 0 deletions