]> asedeno.scripts.mit.edu Git - linux.git/commit
virtiofs: Do not end request in submission context
authorVivek Goyal <vgoyal@redhat.com>
Tue, 15 Oct 2019 17:46:22 +0000 (13:46 -0400)
committerMiklos Szeredi <mszeredi@redhat.com>
Mon, 21 Oct 2019 13:57:07 +0000 (15:57 +0200)
commit51fecdd2555b3e0e05a78d30093c638d164a32f9
tree2760e95ff51c29ca24d74a8ba2c4a32e396621ce
parent6c26f71759a6efc04b888dd2c1cc4f1cac38cdf0
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>
fs/fuse/virtio_fs.c