On Thu, Sep 27, 2018 at 9:15 PM Pingfan Liu <kernelfans@xxxxxxxxx> wrote:
>
> On Thu, Sep 27, 2018 at 12:14 AM Christopher Lameter <cl@xxxxxxxxx> wrote:
> >
> > On Wed, 26 Sep 2018, Pingfan Liu wrote:
> >
> > > -
> > > if (unlikely(!freelist)) {
> > > slab_out_of_memory(s, gfpflags, node);
> > > return NULL;
> > > }
> > >
> > > + VM_BUG_ON(!pfmemalloc_match(page, gfpflags));
> > > page = c->page;
> > > - if (likely(!kmem_cache_debug(s) && pfmemalloc_match(page, gfpflags)))
> > > + if (likely(!kmem_cache_debug(s))
> > > goto load_freelist;
> > >
> > > /* Only entered in the debug case */
> > > - if (kmem_cache_debug(s) &&
> > > - !alloc_debug_processing(s, page, freelist, addr))
> > > + if (!alloc_debug_processing(s, page, freelist, addr))
> > > goto new_slab; /* Slab failed checks. Next slab needed */
> > > -
> > > - deactivate_slab(s, page, get_freepointer(s, freelist), c);
> >
> > In the debug case the slab needs to be deactivated. Otherwise the
> > slowpath will not be used and debug checks on the following objects will
> > not be done.
> >
After taking a more closely look at the debug code, I consider whether
the alloc_debug_processing() can be also called after get_freelist(s,
page), then deactivate_slab() is not required . My justification is
the debug code will take the same code path as the non-debug, hence
the page will experience the same transition on different list like
the non-debug code, and help to detect the bug, also it will improve
scalability on SMP.
Besides this, I found the debug code is not scalable well, is it worth
to work on it?
Thanks,
Pingfan
