linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Linux-MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: Add additional consistency check
Date: Tue, 11 Apr 2017 13:44:02 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1704111335540.6544@east.gentwo.org> (raw)
In-Reply-To: <20170411183035.GD21171@dhcp22.suse.cz>

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. 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.

Making both allocators consistent is ok with me and is a improvement of
the code.




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-04-11 18:44 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 16:40 Kees Cook
2017-03-31 21:33 ` Andrew Morton
2017-04-01  0:04   ` Kees Cook
2017-04-03  3:40     ` Michael Ellerman
2017-04-03 14:03       ` Christoph Lameter
2017-04-03 14:53         ` Matthew Wilcox
2017-04-04 11:30 ` Michal Hocko
2017-04-04 15:07   ` Christoph Lameter
2017-04-04 15:16     ` Michal Hocko
2017-04-04 15:46       ` Kees Cook
2017-04-04 15:58         ` Michal Hocko
2017-04-04 16:02           ` Kees Cook
2017-04-04 19:13       ` Christoph Lameter
2017-04-04 19:42         ` Michal Hocko
2017-04-04 19:58           ` Christoph Lameter
2017-04-04 20:13             ` Michal Hocko
2017-04-11  4:58               ` Kees Cook
2017-04-11 13:46                 ` Michal Hocko
2017-04-11 14:14                   ` Kees Cook
2017-04-11 14:19                     ` Michal Hocko
2017-04-11 16:05                       ` Kees Cook
2017-04-11 16:16                       ` Christoph Lameter
2017-04-11 16:19                         ` Kees Cook
2017-04-11 16:23                           ` Christoph Lameter
2017-04-11 16:30                             ` Kees Cook
2017-04-11 16:26                           ` Christoph Lameter
2017-04-11 16:41                         ` Michal Hocko
2017-04-11 18:03                           ` Christoph Lameter
2017-04-11 18:30                             ` Michal Hocko
2017-04-11 18:44                               ` Christoph Lameter [this message]
2017-04-11 18:55                                 ` Michal Hocko
2017-04-11 18:59                                   ` Christoph Lameter
2017-04-11 19:39                                     ` Michal Hocko
2017-04-17 15:22                                       ` Christoph Lameter
2017-04-18  6:41                                         ` Michal Hocko
2017-04-18 13:31                                           ` Christoph Lameter
2017-04-18 13:37                                           ` Christoph Lameter
2017-04-28  1:11                       ` Kees Cook
2017-04-28  6:16                         ` Michal Hocko
2017-04-27 12:06   ` Michal Hocko
2017-04-11 18:30 ` Christoph Lameter

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=alpine.DEB.2.20.1704111335540.6544@east.gentwo.org \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox