From: Dave Hansen <dave.hansen@intel.com>
To: Shakeel Butt <shakeelb@google.com>, Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Christoph Lameter <cl@linux.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] slub: Don't panic for memcg kmem cache creation failure
Date: Thu, 20 Jun 2019 07:51:50 -0700 [thread overview]
Message-ID: <e7ce6ea7-50fc-78ad-1394-4da11cba7ad3@intel.com> (raw)
In-Reply-To: <CALvZod4Fd5X91CzDLaVAvspQL-zoD7+9OGTiOro-hiMda=DqBA@mail.gmail.com>
On 6/20/19 7:44 AM, Shakeel Butt wrote:
>> I am wondering whether SLAB_PANIC makes sense in general though. Why is
>> it any different from any other essential early allocations? We tend to
>> not care about allocation failures for those on bases that the system
>> must be in a broken state to fail that early already. Do you think it is
>> time to remove SLAB_PANIC altogether?
>>
> That would need some investigation into the history of SLAB_PANIC. I
> will look into it.
I think it still makes sense for things like the vma, filp, dentry
caches. If we don't
have those, we can't even execve("/sbin/init") so we shouldn't even bother
continuing to boot.
Maybe we should turn off SLAB_PANIC behavior after boot. We don't want
a silly driver or filesystem module that's creating slabs to be causing
panic()s.
next prev parent reply other threads:[~2019-06-20 14:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 23:25 [PATCH] slub: Don't panic for memcg kmem cache creation failure Shakeel Butt
2019-06-20 5:50 ` Michal Hocko
2019-06-20 14:44 ` Shakeel Butt
2019-06-20 14:51 ` Dave Hansen [this message]
2019-06-20 15:35 ` Michal Hocko
2019-06-21 20:52 ` David Rientjes
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=e7ce6ea7-50fc-78ad-1394-4da11cba7ad3@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shakeelb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.