linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	LKML <linux-kernel@vger.kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>
Subject: memcg/kmem panics
Date: Wed, 19 Jun 2019 15:50:45 -0700	[thread overview]
Message-ID: <e5cfe17c-a59f-b1d1-19ce-590245106068@intel.com> (raw)

I have a bit of a grievance to file.  :)

I'm seeing "Cannot create slab..." panic()s coming from
kmem_cache_open() when trying to create memory cgroups on a Fedora
system running 5.2-rc's.  The panic()s happen when failing to create
memcg-specific slabs because the memcg code passes through the
root_cache->flags, which can include SLAB_PANIC.

I haven't tracked down the root cause yet, or where this behavior
started.  But, the end-user experience is that systemd tries to create a
cgroup and ends up with a kernel panic.  That's rather sad, especially
for the poor sod that's trying to debug it.

Should memcg_create_kmem_cache() be, perhaps filtering out SLAB_PANIC
from root_cache->flags, for instance?  That might make the system a bit
less likely to turn into a doorstop if and when something goes mildly
wrong.  I've hacked out the panic()s and the system actually seems to
boot OK.

BTW, this particular system has some persistent memory in it.  I suspect
there's something wrong where the slab code is trying to create slabs
for pmem-only nodes.  But,


             reply	other threads:[~2019-06-19 22:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19 22:50 Dave Hansen [this message]
2019-06-19 23:04 ` 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=e5cfe17c-a59f-b1d1-19ce-590245106068@intel.com \
    --to=dave.hansen@intel.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --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