summaryrefslogtreecommitdiff
path: root/drivers/block/null_blk.c
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2018-02-28 03:56:43 +0300
committerJens Axboe <axboe@kernel.dk>2018-02-28 22:23:35 +0300
commit4ace53f1ed40a5cfee4bdd7614c8a8b2798227ad (patch)
treec766967b9ac9c5ae7a04035c0fa182fb27167d33 /drivers/block/null_blk.c
parente9a99a638800af25c7ed006c96fd1dabb99254b7 (diff)
downloadlinux-4ace53f1ed40a5cfee4bdd7614c8a8b2798227ad.tar.xz
sbitmap: use test_and_set_bit_lock()/clear_bit_unlock()
sbitmap_queue_get()/sbitmap_queue_clear() are used for allocating/freeing a resource, so they should provide acquire/release barrier semantics, respectively. sbitmap_get() currently contains a full barrier, which is unnecessary, so use test_and_set_bit_lock() instead of test_and_set_bit() (these are equivalent on x86_64). sbitmap_clear_bit() does not imply any barriers, which is incorrect, as accesses of the resource (e.g., request) could potentially get reordered to after the clear_bit(). Introduce sbitmap_clear_bit_unlock() and use it for sbitmap_queue_clear() (this only adds a compiler barrier on x86_64). The other existing user of sbitmap_clear_bit() (the blk-mq software queue pending map) is serialized through a spinlock and does not need this. Reported-by: Tejun Heo <tj@kernel.org> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'drivers/block/null_blk.c')
0 files changed, 0 insertions, 0 deletions