From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH] slub: Don't panic for memcg kmem cache creation failure Date: Thu, 20 Jun 2019 07:51:50 -0700 Message-ID: References: <20190619232514.58994-1-shakeelb@google.com> <20190620055028.GA12083@dhcp22.suse.cz> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Shakeel Butt , Michal Hocko Cc: Johannes Weiner , Christoph Lameter , Andrew Morton , Roman Gushchin , Pekka Enberg , David Rientjes , Joonsoo Kim , Cgroups , Linux MM , LKML 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.