Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753347AbdDKS4C (ORCPT ); Tue, 11 Apr 2017 14:56:02 -0400 Received: from mx2.suse.de ([195.135.220.15]:46589 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997AbdDKSz7 (ORCPT ); Tue, 11 Apr 2017 14:55:59 -0400 Date: Tue, 11 Apr 2017 20:55:56 +0200 From: Michal Hocko To: Christoph Lameter Cc: Kees Cook , Andrew Morton , Pekka Enberg , David Rientjes , Joonsoo Kim , Linux-MM , LKML Subject: Re: [PATCH] mm: Add additional consistency check Message-ID: <20170411185555.GE21171@dhcp22.suse.cz> References: <20170404201334.GV15132@dhcp22.suse.cz> <20170411134618.GN6729@dhcp22.suse.cz> <20170411141956.GP6729@dhcp22.suse.cz> <20170411164134.GA21171@dhcp22.suse.cz> <20170411183035.GD21171@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1387 Lines: 33 On Tue 11-04-17 13:44:02, Cristopher Lameter wrote: > On Tue, 11 Apr 2017, Michal Hocko wrote: > > > > So we are already handling that condition. Why change things? Add a BUG_ON > > > if you want to make SLAB consistent. > > > > I hate to repeat myself but let me do it for the last time in this > > thread. BUG_ON for something that is recoverable is completely > > inappropriate. And I consider kfree with a bogus pointer something that > > we can easily recover from. There are other cases where the internal > > state of the allocator is compromised to the point where continuing is > > not possible and BUGing there is acceptable but kfree(garbage) is not > > that case. > > kfree(garbage) by the core kernel has so far been taken as a sign of > severe memory corruption and the kernels have been oopsing when this > occurred. This has been that way for a decade or so. which doesn't make it a valid decision. We just overuse BUG* > kfree() is used by > the allocators and various other core kernel components. If the metadata > of the core kernel is compromised then it is safest to stop right there. > > If you want to change things then someone has to do some work. What you > are saying is not the way things are implemented. Sorry. I didn't say anything like that. Hence the proposed patch which still needs some more thinking and evaluation. -- Michal Hocko SUSE Labs