Thread (11 messages) 11 messages, 4 authors, 2017-08-28

Re: [PATCH 1/2] mm: Track actual nr_scanned during shrink_slab()

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2017-08-25 21:42:00
Also in: intel-gfx

On Thu, 24 Aug 2017 10:00:49 +0200 Vlastimil Babka [off-list ref] wrote:
quoted
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help