From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 1/2] mm: Track actual nr_scanned during shrink_slab() Date: Fri, 25 Aug 2017 14:41:56 -0700 Message-ID: <20170825144156.f70bfad8dd982d1a320e41ca@linux-foundation.org> References: <20170815153010.e3cfc177af0b2c0dc421b84c@linux-foundation.org> <20170822135325.9191-1-chris@chris-wilson.co.uk> <20170824051153.GB13922@bgram> <29aae2cd-85a8-f3c4-66e2-4d4f5a2732c1@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <29aae2cd-85a8-f3c4-66e2-4d4f5a2732c1@suse.cz> Sender: owner-linux-mm@kvack.org To: Vlastimil Babka Cc: Minchan Kim , Chris Wilson , linux-mm@kvack.org, intel-gfx@lists.freedesktop.org, Michal Hocko , Johannes Weiner , Hillf Danton , Mel Gorman , Shaohua Li List-Id: intel-gfx@lists.freedesktop.org On Thu, 24 Aug 2017 10:00:49 +0200 Vlastimil Babka wrote: > > Even if a > > shrinker has a mistake, VM will have big trouble like infinite loop. > > We could fake 0 as 1 or something, at least. If the shrinker returns sc->nr_scanned==0 then that's a buggy shrinker - it should return SHRINK_STOP in that case. Only a single shrinker (i915) presently uses sc->nr_scanned and that one gets it right. I think it's OK - there's a limit to how far we should go defending against buggy kernel code, surely. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org