vmscan: shrinker->nr updates race and go wrong
commitacf92b485cccf028177f46918e045c0c4e80ee10
authorDave Chinner <dchinner@redhat.com>
Fri, 8 Jul 2011 04:14:35 +0000 (8 14:14 +1000)
committerAl Viro <viro@zeniv.linux.org.uk>
Wed, 20 Jul 2011 05:44:29 +0000 (20 01:44 -0400)
tree7da97439b5388d143cf414874572f1b2da7f3fe3
parent095760730c1047c69159ce88021a7fa3833502c8
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>
mm/vmscan.c