[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Apr 2017 22:13:34 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Christoph Lameter <cl@...ux.com>
Cc: Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: Add additional consistency check
On Tue 04-04-17 14:58:06, Cristopher Lameter wrote:
> On Tue, 4 Apr 2017, Michal Hocko wrote:
>
> > On Tue 04-04-17 14:13:06, Cristopher Lameter wrote:
> > > On Tue, 4 Apr 2017, Michal Hocko wrote:
> > >
> > > > Yes, but we do not have to blow the kernel, right? Why cannot we simply
> > > > leak that memory?
> > >
> > > Because it is a serious bug to attempt to free a non slab object using
> > > slab operations. This is often the result of memory corruption, coding
> > > errs etc. The system needs to stop right there.
> >
> > Why when an alternative is a memory leak?
>
> Because the slab allocators fail also in case you free an object multiple
> times etc etc. Continuation is supported by enabling a special resiliency
> feature via the kernel command line. The alternative is selectable but not
> the default.
I disagree! We should try to continue as long as we _know_ that the
internal state of the allocator is still consistent and a further
operation will not spread the corruption even more. This is clearly not
the case for an invalid pointer to kfree.
I can see why checking for an early allocator corruption is not always
feasible and you can only detect after-the-fact but this is not the case
here and putting your system down just because some buggy code is trying
to free something it hasn't allocated is not really useful. I completely
agree with Linus that we overuse BUG way too much and this is just
another example of it.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists