diff options
author | Waiman Long <longman@redhat.com> | 2017-09-20 13:12:20 -0600 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2017-09-25 08:56:05 -0600 |
commit | 5acb3cc2c2e9d3020a4fee43763c6463767f1572 (patch) | |
tree | 0d650e446e8e7ef738e3d2237b6778fb6ef447a4 /block/blk-timeout.c | |
parent | 1dae69bedeeca0b57e441eae491fbd38049c0b47 (diff) | |
download | lwn-5acb3cc2c2e9d3020a4fee43763c6463767f1572.tar.gz lwn-5acb3cc2c2e9d3020a4fee43763c6463767f1572.zip |
blktrace: Fix potential deadlock between delete & sysfs ops
The lockdep code had reported the following unsafe locking scenario:
CPU0 CPU1
---- ----
lock(s_active#228);
lock(&bdev->bd_mutex/1);
lock(s_active#228);
lock(&bdev->bd_mutex);
*** DEADLOCK ***
The deadlock may happen when one task (CPU1) is trying to delete a
partition in a block device and another task (CPU0) is accessing
tracing sysfs file (e.g. /sys/block/dm-1/trace/act_mask) in that
partition.
The s_active isn't an actual lock. It is a reference count (kn->count)
on the sysfs (kernfs) file. Removal of a sysfs file, however, require
a wait until all the references are gone. The reference count is
treated like a rwsem using lockdep instrumentation code.
The fact that a thread is in the sysfs callback method or in the
ioctl call means there is a reference to the opended sysfs or device
file. That should prevent the underlying block structure from being
removed.
Instead of using bd_mutex in the block_device structure, a new
blk_trace_mutex is now added to the request_queue structure to protect
access to the blk_trace structure.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Waiman Long <longman@redhat.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fix typo in patch subject line, and prune a comment detailing how
the code used to work.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'block/blk-timeout.c')
0 files changed, 0 insertions, 0 deletions