Re: [PATCH 03/33] mm: slub: add knowledge of reserve pages
From: Peter Zijlstra <hidden>
Date: 2007-10-31 12:18:15
Also in:
linux-mm, lkml
On Wed, 2007-10-31 at 21:46 +1100, Nick Piggin wrote:
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:quoted
On Wed, 2007-10-31 at 14:37 +1100, Nick Piggin wrote:quoted
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:quoted
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation contexts that are entitled to it. Care is taken to only touch the SLUB slow path. This is done to ensure reserve pages don't leak out and get consumed.I think this is generally a good idea (to prevent slab allocators from stealing reserve). However I naively think the implementation is a bit overengineered and thus has a few holes. Humour me, what was the problem with failing the slab allocation (actually, not fail but just call into the page allocator to do correct waiting / reclaim) in the slowpath if the process fails the watermark checks?Ah, we actually need slabs below the watermarks.Right, I'd still allow those guys to allocate slabs. Provided they have the right allocation context, right?quoted
Its just that once I allocated those slabs using __GFP_MEMALLOC/PF_MEMALLOC I don't want allocation contexts that do not have rights to those pages to walk off with objects.And I'd prevent these ones from doing so. Without keeping track of "reserve" pages, which doesn't feel too clean.
The problem with that is that once a slab was allocated with the right
allocation context, anybody can get objects from these slabs.
low memory, and empty slab:
task A task B
kmem_cache_alloc() = NULL
current->flags |= PF_MEMALLOC
kmem_cache_alloc() = obj
(slab != NULL)
kmem_cache_alloc() = obj
kmem_cache_alloc() = obj
kmem_cache_alloc() = obj
And now task A, who doesn't have the right permissions walks
away with all our reserve memory.
So we either reserve a page per object, which for 32 byte objects is a
large waste, or we stop anybody who doesn't have the right permissions
from obtaining objects. I took the latter approach.
Attachments
- signature.asc [application/pgp-signature] 189 bytes