summaryrefslogtreecommitdiffstats
path: root/fs/minix
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2018-02-27 16:56:42 -0800
committerJens Axboe <axboe@kernel.dk>2018-02-28 12:23:35 -0700
commite9a99a638800af25c7ed006c96fd1dabb99254b7 (patch)
treed23b4989804cd48bb248142f9fa6370bd2700a2c /fs/minix
parent18bc42308699522b57fd599401c03ad561f422ef (diff)
downloadlinux-e9a99a638800af25c7ed006c96fd1dabb99254b7.tar.gz
linux-e9a99a638800af25c7ed006c96fd1dabb99254b7.tar.bz2
linux-e9a99a638800af25c7ed006c96fd1dabb99254b7.zip
block: clear ctx pending bit under ctx lock
When we insert a request, we set the software queue pending bit while holding the software queue lock. However, we clear it outside of the lock, so it's possible that a concurrent insert could reset the bit after we clear it but before we empty the request list. Afterwards, the bit would still be set but the software queue wouldn't have any requests in it, leading us to do a spurious run in the future. This is mostly a benign/theoretical issue, but it makes the following change easier to justify. Signed-off-by: Omar Sandoval <osandov@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'fs/minix')
0 files changed, 0 insertions, 0 deletions