diff options
author | Waiman Long <[email protected]> | 2017-09-20 13:12:20 -0600 |
---|---|---|
committer | Jens Axboe <[email protected]> | 2017-09-25 08:56:05 -0600 |
commit | 5acb3cc2c2e9d3020a4fee43763c6463767f1572 (patch) | |
tree | 0d650e446e8e7ef738e3d2237b6778fb6ef447a4 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 1dae69bedeeca0b57e441eae491fbd38049c0b47 (diff) |
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 <[email protected]>
Signed-off-by: Waiman Long <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
Fix typo in patch subject line, and prune a comment detailing how
the code used to work.
Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions