diff options
author | Omar Sandoval <osandov@fb.com> | 2018-02-28 03:56:43 +0300 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2018-02-28 22:23:35 +0300 |
commit | 4ace53f1ed40a5cfee4bdd7614c8a8b2798227ad (patch) | |
tree | c766967b9ac9c5ae7a04035c0fa182fb27167d33 /drivers/block/null_blk.c | |
parent | e9a99a638800af25c7ed006c96fd1dabb99254b7 (diff) | |
download | linux-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