dm cache: fix race affecting dirty block count
commit 44fa816b upstream. nr_dirty is updated without locking, causing it to drift so that it is non-zero (either a small positive integer, or a very large one when an underflow occurs) even when there are no actual dirty blocks. This was due to a race between the workqueue and map function accessing nr_dirty in parallel without proper protection. People were seeing under runs due to a race on increment/decrement of nr_dirty, see: https://lkml.org/lkml/2014/6/3/648 Fix this by using an atomic_t for nr_dirty. Reported-by: roma1390@gmail.com Signed-off-by:Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> [ luis: backported to 3.11: adjusted context ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
Showing
Please register or sign in to comment