Skip to content

Commit 9fc75b7

Browse files
committed
rbd: eliminate a race in lock_dwork draining on unmap
Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request. This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation. A more problematic example is maybe_kick_acquire(): if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) { dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev); mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0); } It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway. This is a classic TOCTOU race. When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire(). This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated rbd_assert(rbd_image_format_valid(rbd_dev->image_format)); in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action(). Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock(). Cc: stable@vger.kernel.org Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
1 parent 5200f5f commit 9fc75b7

1 file changed

Lines changed: 8 additions & 12 deletions

File tree

drivers/block/rbd.c

Lines changed: 8 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -4565,24 +4565,12 @@ static int rbd_register_watch(struct rbd_device *rbd_dev)
45654565
return ret;
45664566
}
45674567

4568-
static void cancel_tasks_sync(struct rbd_device *rbd_dev)
4569-
{
4570-
dout("%s rbd_dev %p\n", __func__, rbd_dev);
4571-
4572-
cancel_work_sync(&rbd_dev->acquired_lock_work);
4573-
cancel_work_sync(&rbd_dev->released_lock_work);
4574-
cancel_delayed_work_sync(&rbd_dev->lock_dwork);
4575-
cancel_work_sync(&rbd_dev->unlock_work);
4576-
}
4577-
45784568
/*
45794569
* header_rwsem must not be held to avoid a deadlock with
45804570
* rbd_dev_refresh() when flushing notifies.
45814571
*/
45824572
static void rbd_unregister_watch(struct rbd_device *rbd_dev)
45834573
{
4584-
cancel_tasks_sync(rbd_dev);
4585-
45864574
mutex_lock(&rbd_dev->watch_mutex);
45874575
if (rbd_dev->watch_state == RBD_WATCH_STATE_REGISTERED)
45884576
__rbd_unregister_watch(rbd_dev);
@@ -6548,10 +6536,18 @@ static int rbd_add_parse_args(const char *buf,
65486536

65496537
static void rbd_dev_image_unlock(struct rbd_device *rbd_dev)
65506538
{
6539+
dout("%s rbd_dev %p\n", __func__, rbd_dev);
6540+
6541+
disable_delayed_work_sync(&rbd_dev->lock_dwork);
6542+
disable_work_sync(&rbd_dev->unlock_work);
6543+
65516544
down_write(&rbd_dev->lock_rwsem);
65526545
if (__rbd_is_lock_owner(rbd_dev))
65536546
__rbd_release_lock(rbd_dev);
65546547
up_write(&rbd_dev->lock_rwsem);
6548+
6549+
flush_work(&rbd_dev->acquired_lock_work);
6550+
flush_work(&rbd_dev->released_lock_work);
65556551
}
65566552

65576553
/*

0 commit comments

Comments
 (0)