Re: [PATCH v2 2/2] slab: __GFP_ZERO is incompatible with a constructor
From: Christopher Lameter
Date: Thu Apr 12 2018 - 10:10:32 EST
On Wed, 11 Apr 2018, Matthew Wilcox wrote:
>
> I don't see how that works ... can you explain a little more?
>
> I see ___slab_alloc() is called from __slab_alloc(). And I see
> slab_alloc_node does this:
>
> object = c->freelist;
> page = c->page;
> if (unlikely(!object || !node_match(page, node))) {
> object = __slab_alloc(s, gfpflags, node, addr, c);
> stat(s, ALLOC_SLOWPATH);
>
> But I don't see how slub_debug leads to c->freelist always being NULL.
> It looks like it gets repopulated from page->freelist in ___slab_alloc()
> at the load_freelist label.
c->freelist is NULL and thus ___slab_alloc (slowpath) is called.
___slab_alloc populates c->freelist and gets the new object pointer.
if debugging is on then c->freelist is set to NULL at the end of
___slab_alloc because deactivate_slab() is called.
Thus the next invocation of the fastpath will find that c->freelist is
NULL and go to the slowpath. ...