summaryrefslogtreecommitdiffstats
path: root/drivers/md/dm-snap-persistent.c
diff options
context:
space:
mode:
authorMikulas Patocka <mpatocka@redhat.com>2023-11-17 18:21:14 +0100
committerMike Snitzer <snitzer@kernel.org>2023-11-17 20:38:46 +0100
commit6fc45b6ed921dc00dfb264dc08c7d67ee63d2656 (patch)
treebd99f7681d41331bb1fc88a47d7ec26229414ebc /drivers/md/dm-snap-persistent.c
parentLinux 6.7-rc1 (diff)
downloadlinux-6fc45b6ed921dc00dfb264dc08c7d67ee63d2656.tar.xz
linux-6fc45b6ed921dc00dfb264dc08c7d67ee63d2656.zip
dm-delay: fix a race between delay_presuspend and delay_bio
In delay_presuspend, we set the atomic variable may_delay and then stop the timer and flush pending bios. The intention here is to prevent the delay target from re-arming the timer again. However, this test is racy. Suppose that one thread goes to delay_bio, sees that dc->may_delay is one and proceeds; now, another thread executes delay_presuspend, it sets dc->may_delay to zero, deletes the timer and flushes pending bios. Then, the first thread continues and adds the bio to delayed->list despite the fact that dc->may_delay is false. Fix this bug by changing may_delay's type from atomic_t to bool and only access it while holding the delayed_bios_lock mutex. Note that we don't have to grab the mutex in delay_resume because there are no bios in flight at this point. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Diffstat (limited to 'drivers/md/dm-snap-persistent.c')
0 files changed, 0 insertions, 0 deletions