[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160809160612.GH1983@esperanza>
Date: Tue, 9 Aug 2016 19:06:12 +0300
From: Vladimir Davydov <vdavydov@...tuozzo.com>
To: Chris Wilson <chris@...is-wilson.co.uk>
CC: <linux-kernel@...r.kernel.org>, Christoph Lameter <cl@...ux.com>,
"Pekka Enberg" <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
"Joonsoo Kim" <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Dmitry Safonov <dsafonov@...tuozzo.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Dave Gordon <david.s.gordon@...el.com>, <linux-mm@...ck.org>
Subject: Re: [PATCH v2] mm/slub: Run free_partial() outside of the
kmem_cache_node->list_lock
On Tue, Aug 09, 2016 at 04:52:13PM +0100, Chris Wilson wrote:
...
> > > @@ -3486,13 +3487,16 @@ static void free_partial(struct kmem_cache *s, struct kmem_cache_node *n)
> > > list_for_each_entry_safe(page, h, &n->partial, lru) {
> > > if (!page->inuse) {
> > > remove_partial(n, page);
> > > - discard_slab(s, page);
> > > + list_add(&page->lru, &partial_list);
> >
> > If there are objects left in the cache on destruction, the cache won't
> > be destroyed. Instead it will be left on the slab_list and can get
> > reused later. So we should use list_move() here to always leave
> > n->partial in a consistent state, even in case of a leak.
>
> Since remove_partial() does an unconditional list_del(),
> I presume you want to perform the list_move() even if we hit the error
> path, right?
Please ignore my previous remark - I missed that remove_partial() does
list_del(), so using list_add(), as you did in v2, should be just fine.
Feel free, to add
Reviewed-by: Vladimir Davydov <vdavydov@...tuozzo.com>
Thanks,
Vladimir
Powered by blists - more mailing lists