summaryrefslogtreecommitdiffstats
path: root/block/blk-cgroup.c
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2017-01-18 20:55:22 +0100
committerJens Axboe <axboe@fb.com>2017-01-18 21:41:55 +0100
commit6c0ca7ae292adea09b8bdd33a524bb9326c3e989 (patch)
treebbe47f1b91edbae94b582649b7d11a4b2b2fb877 /block/blk-cgroup.c
parentsbitmap: use smp_mb__after_atomic() in sbq_wake_up() (diff)
downloadlinux-6c0ca7ae292adea09b8bdd33a524bb9326c3e989.tar.xz
linux-6c0ca7ae292adea09b8bdd33a524bb9326c3e989.zip
sbitmap: fix wakeup hang after sbq resize
When we resize a struct sbitmap_queue, we update the wakeup batch size, but we don't update the wait count in the struct sbq_wait_states. If we resized down from a size which could use a bigger batch size, these counts could be too large and cause us to miss necessary wakeups. To fix this, update the wait counts when we resize (ensuring some careful memory ordering so that it's safe w.r.t. concurrent clears). This also fixes a theoretical issue where two threads could end up bumping the wait count up by the batch size, which could also potentially lead to hangs. Reported-by: Martin Raiber <martin@urbackup.org> Fixes: e3a2b3f931f5 ("blk-mq: allow changing of queue depth through sysfs") Fixes: 2971c35f3588 ("blk-mq: bitmap tag: fix race on blk_mq_bitmap_tags::wake_cnt") Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to 'block/blk-cgroup.c')
0 files changed, 0 insertions, 0 deletions