linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	Kernel Team <Kernel-team@fb.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"longman@redhat.com" <longman@redhat.com>,
	"shakeelb@google.com" <shakeelb@google.com>,
	"vdavydov.dev@gmail.com" <vdavydov.dev@gmail.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: WARNING bisected (was Re: [PATCH v7 08/10] mm: rework non-root kmem_cache lifecycle management)
Date: Mon, 25 Nov 2019 18:07:50 +0000	[thread overview]
Message-ID: <20191125180744.GA9800@localhost.localdomain> (raw)
In-Reply-To: <e2923bb7-19bf-b303-9457-49040acffe92@de.ibm.com>

On Mon, Nov 25, 2019 at 09:00:56AM +0100, Christian Borntraeger wrote:
> 
> 
> On 24.11.19 01:39, Roman Gushchin wrote:
> > On Fri, Nov 22, 2019 at 05:28:46PM +0100, Christian Borntraeger wrote:
> >> On 21.11.19 19:45, Roman Gushchin wrote:
> >>> I see. Do you know, which kmem_cache it is? If not, can you, please,
> >>> figure it out?
> >>
> >> The release function for that ref is kmemcg_cache_shutdown. 
> >>
> > 
> > Hi Christian!
> > 
> > Can you, please, test if the following patch resolves the problem?
> 
> Yes, it does.

Thanks for testing it!
I'll send the patch shortly.

> 
> 
> > 
> > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > index 8afa188f6e20..628e5f0ee19e 100644
> > --- a/mm/slab_common.c
> > +++ b/mm/slab_common.c
> > @@ -888,6 +888,8 @@ static int shutdown_memcg_caches(struct kmem_cache *s)
> >  
> >  static void flush_memcg_workqueue(struct kmem_cache *s)
> >  {
> > +	bool wait_for_children;
> > +
> >  	spin_lock_irq(&memcg_kmem_wq_lock);
> >  	s->memcg_params.dying = true;
> >  	spin_unlock_irq(&memcg_kmem_wq_lock);
> > @@ -904,6 +906,13 @@ static void flush_memcg_workqueue(struct kmem_cache *s)
> >  	 * previous workitems on workqueue are processed.
> >  	 */
> >  	flush_workqueue(memcg_kmem_cache_wq);
> > +
> > +	mutex_lock(&slab_mutex);
> > +	wait_for_children = !list_empty(&s->memcg_params.children);
> > +	mutex_unlock(&slab_mutex);
> 
> Not sure if (for reading) we really need the mutex.

Good point!
At this moment the list of children caches can't grow, only shrink.
So if we're reading it without the slab mutex, the worst thing can
happen is that we'll make an excessive rcu_barrier() call.
Which is fine given that resulting code looks much simpler.

Thanks!


  reply	other threads:[~2019-11-25 18:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 23:18 [PATCH v7 00/10] mm: reparent slab memory on cgroup removal Roman Gushchin
2019-06-11 23:18 ` [PATCH v7 01/10] mm: postpone kmem_cache memcg pointer initialization to memcg_link_cache() Roman Gushchin
2019-06-13  2:04   ` Andrew Morton
2019-06-13 16:25     ` Roman Gushchin
2019-06-11 23:18 ` [PATCH v7 02/10] mm: rename slab delayed deactivation functions and fields Roman Gushchin
2019-06-25 18:17   ` Shakeel Butt
2019-06-11 23:18 ` [PATCH v7 03/10] mm: generalize postponed non-root kmem_cache deactivation Roman Gushchin
2019-06-25 18:17   ` Shakeel Butt
2019-06-11 23:18 ` [PATCH v7 04/10] mm: introduce __memcg_kmem_uncharge_memcg() Roman Gushchin
2019-06-11 23:18 ` [PATCH v7 05/10] mm: unify SLAB and SLUB page accounting Roman Gushchin
2019-06-11 23:18 ` [PATCH v7 06/10] mm: don't check the dying flag on kmem_cache creation Roman Gushchin
2019-06-16 16:26   ` Vladimir Davydov
2019-06-25 18:31   ` Shakeel Butt
2019-06-11 23:18 ` [PATCH v7 07/10] mm: synchronize access to kmem_cache dying flag using a spinlock Roman Gushchin
2019-06-16 16:27   ` Vladimir Davydov
2019-06-25 18:33   ` Shakeel Butt
2019-06-11 23:18 ` [PATCH v7 08/10] mm: rework non-root kmem_cache lifecycle management Roman Gushchin
2019-06-25 23:57   ` Shakeel Butt
2019-11-21 11:17   ` WARNING bisected (was Re: [PATCH v7 08/10] mm: rework non-root kmem_cache lifecycle management) Christian Borntraeger
2019-11-21 13:08     ` Christian Borntraeger
2019-11-21 16:58     ` Roman Gushchin
2019-11-21 16:59       ` Christian Borntraeger
2019-11-21 18:45         ` Roman Gushchin
2019-11-21 20:43           ` Rik van Riel
2019-11-21 20:55             ` Roman Gushchin
2019-11-21 22:09               ` Roman Gushchin
2019-11-22 13:00                 ` Christian Borntraeger
2019-11-22 16:28           ` Christian Borntraeger
2019-11-24  0:39             ` Roman Gushchin
2019-11-25  8:00               ` Christian Borntraeger
2019-11-25 18:07                 ` Roman Gushchin [this message]
2019-06-11 23:18 ` [PATCH v7 09/10] mm: stop setting page->mem_cgroup pointer for slab pages Roman Gushchin
2019-06-26  0:15   ` Shakeel Butt
2019-06-11 23:18 ` [PATCH v7 10/10] mm: reparent memcg kmem_caches on cgroup removal Roman Gushchin
2019-06-16 16:29   ` Vladimir Davydov
2019-06-26  0:15   ` Shakeel Butt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191125180744.GA9800@localhost.localdomain \
    --to=guro@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=frankja@linux.ibm.com \
    --cc=hannes@cmpxchg.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=shakeelb@google.com \
    --cc=vdavydov.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox