Thread (71 messages) 71 messages, 14 authors, 2007-11-18

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help