linux-kernel - memcg/kmem panics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Jun 2019 15:50:45 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        cgroups@...r.kernel.org, linux-mm@...ck.org,
        LKML <linux-kernel@...r.kernel.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>
Subject: memcg/kmem panics

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,