Dave Chinner acf92b485c vmscan: shrinker->nr updates race and go wrong
shrink_slab() allows shrinkers to be called in parallel so the
struct shrinker can be updated concurrently. It does not provide any
exclusio for such updates, so we can get the shrinker->nr value
increasing or decreasing incorrectly.

As a result, when a shrinker repeatedly returns a value of -1 (e.g.
a VFS shrinker called w/ GFP_NOFS), the shrinker->nr goes haywire,
sometimes updating with the scan count that wasn't used, sometimes
losing it altogether. Worse is when a shrinker does work and that
update is lost due to racy updates, which means the shrinker will do
the work again!

Fix this by making the total_scan calculations independent of
shrinker->nr, and making the shrinker->nr updates atomic w.r.t. to
other updates via cmpxchg loops.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-07-20 01:44:29 -04:00
..
2009-04-01 08:59:13 -07:00
2011-06-03 18:24:58 -04:00
2011-05-26 09:20:31 -07:00
2011-03-31 11:26:23 -03:00
2009-09-22 07:17:35 -07:00
2011-05-26 09:20:31 -07:00
2010-03-24 16:31:21 -07:00
2011-01-13 17:32:46 -08:00
2011-05-25 08:39:18 -07:00
2010-05-21 18:31:21 -04:00
2011-07-08 21:14:44 -07:00
2011-03-10 08:52:27 +01:00
2011-05-20 12:50:29 -07:00
2011-06-27 18:00:12 -07:00
2011-03-31 11:26:23 -03:00
2011-03-10 08:52:07 +01:00
2011-05-25 08:39:05 -07:00