blktrace: Fix potential deadlock between delete & sysfs ops
authorWaiman Long <longman@redhat.com>
Wed, 20 Sep 2017 19:12:20 +0000 (13:12 -0600)
committerJens Axboe <axboe@kernel.dk>
Mon, 25 Sep 2017 14:56:05 +0000 (08:56 -0600)
commit5acb3cc2c2e9d3020a4fee43763c6463767f1572
tree0d650e446e8e7ef738e3d2237b6778fb6ef447a4
parent1dae69bedeeca0b57e441eae491fbd38049c0b47
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>
block/blk-core.c
include/linux/blkdev.h
kernel/trace/blktrace.c