Anssi Hannula 44fa816bb7 dm cache: fix race affecting dirty block count
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>
Cc: stable@vger.kernel.org
2014-08-01 12:25:22 -04:00
..
2014-08-01 12:07:21 -04:00
2014-01-14 23:23:03 -05:00
2013-11-23 22:33:47 -08:00
2013-11-09 18:20:22 -05:00
2013-08-23 09:02:13 -04:00
2013-11-23 22:33:47 -08:00
2012-07-30 17:25:16 -07:00
2013-09-05 20:46:06 -04:00
2013-11-23 22:33:47 -08:00
2013-11-23 22:33:47 -08:00
2014-01-14 23:23:04 -05:00
2007-10-20 02:01:26 +01:00
2014-03-27 16:56:24 -04:00
2013-11-23 22:33:47 -08:00
2014-03-27 16:56:23 -04:00
2013-11-23 22:33:57 -08:00
2014-03-27 16:56:23 -04:00
2013-11-23 22:33:47 -08:00
2013-11-23 22:33:57 -08:00
2014-06-11 08:33:41 -07:00