From: Rafael Aquini <aquini@redhat.com>
To: Christopher Lameter <cl@linux.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, iamjoonsoo.kim@lge.com,
rientjes@google.com, penberg@kernel.org
Subject: Re: [PATCH] mm: slub: add panic_on_error to the debug facilities
Date: Sun, 3 May 2020 22:51:38 -0400 [thread overview]
Message-ID: <20200504025138.GB18463@t490s> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2005022313490.1519@www.lameter.com>
On Sat, May 02, 2020 at 11:16:30PM +0000, Christopher Lameter wrote:
> On Fri, 1 May 2020, Rafael Aquini wrote:
>
> > Sometimes it is desirable to override SLUB's debug facilities
> > default behavior upon stumbling on a cache or object error
> > and just stop the execution in order to grab a coredump, at
> > the error-spotting time, instead of trying to fix the issue
> > and report in an attempt to keep the system rolling.
>
> The stopping of execution on an error is the default behavior. Usually
> you get some OOPS somewhere when data is corrupted and that causes a core
> dump.
>
> SLUB can fix the issue and continue if enabled by specifying special
> options on boot. That is *not* the default.
>
It is the default behavior when slub_debug is turned on, which is what
this patch is trying to override, when needed. We've been seeing the
need for such feature as, most often than not, by letting the system
running to crash somewhere else after hitting occurrences reported by
slub_debug ends up clobbering clues to the original issue.
-- Rafael
next prev parent reply other threads:[~2020-05-04 2:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 21:15 Rafael Aquini
2020-05-01 21:29 ` Qian Cai
2020-05-01 21:54 ` Rafael Aquini
2020-05-01 22:00 ` Qian Cai
2020-05-01 23:17 ` Qian Cai
2020-05-04 2:36 ` Rafael Aquini
2020-05-01 21:37 ` Andrew Morton
2020-05-01 21:41 ` Rafael Aquini
2020-05-02 23:16 ` Christopher Lameter
2020-05-04 2:51 ` Rafael Aquini [this message]
2020-05-08 3:06 ` Christopher 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=20200504025138.GB18463@t490s \
--to=aquini@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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