Re: [PATCH] mm/slub: disallow obj's allocation on page with mismatched pfmemalloc purpose

[Pingfan Liu <kernelfans@gmail.com>]

On Thu, Sep 27, 2018 at 9:15 PM Pingfan Liu <kernelfans@gmail.com> wrote:
>
> On Thu, Sep 27, 2018 at 12:14 AM Christopher Lameter <cl@linux.com> 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