linux-kernel - Re: [ 13/40] vmscan: shrinker->nr updates race and go wrong

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1343593770.4642.11.camel@deadeye.wl.decadent.org.uk>
Date:	Sun, 29 Jul 2012 21:29:30 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Dave Chinner <dchinner@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>, Mel Gorman <mgorman@...e.de>
Subject: Re: [ 13/40] vmscan: shrinker->nr updates race and go wrong

On Thu, 2012-07-26 at 14:29 -0700, Greg Kroah-Hartman wrote:
> From: Greg KH <gregkh@...uxfoundation.org>
> 
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Dave Chinner <dchinner@...hat.com>
> 
> commit acf92b485cccf028177f46918e045c0c4e80ee10 upstream.
> 
> Stable note: Not tracked in Bugzilla. This patch reduces excessive
> 	reclaim of slab objects reducing the amount of information
> 	that has to be brought back in from disk.
> 
> 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.
[...]
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -251,17 +251,29 @@ unsigned long shrink_slab(struct shrink_
>  		unsigned long total_scan;
[...]
> +		total_scan += delta;
> +		if (total_scan < 0) {
[...]

This condition is never true since total_scan is unsigned.
I think 3.0.y needs this as well:

commit 635697c663f38106063d5659f0cf2e45afcd4bb5
Author: Konstantin Khlebnikov <khlebnikov@...nvz.org>
Date:   Thu Dec 8 14:33:51 2011 -0800

    vmscan: fix initial shrinker size handling

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain. - Lily Tomlin

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)