diff options
| author | Anssi Hannula <anssi.hannula@iki.fi> | 2014-08-01 11:55:47 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2014-08-07 14:52:37 -0700 |
| commit | 649bf3fdd2ebfd1735b23e46e2387546baa65405 (patch) | |
| tree | 87343b9f319c47ba8c638dba92293a200fd1ae9b /kernel | |
| parent | 549e73fd840ecc84382df856578bf2247fca1c03 (diff) | |
| download | lwn-649bf3fdd2ebfd1735b23e46e2387546baa65405.tar.gz lwn-649bf3fdd2ebfd1735b23e46e2387546baa65405.zip | |
dm cache: fix race affecting dirty block count
commit 44fa816bb778edbab6b6ddaaf24908dd6295937e 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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions