mm: slub: add panic_on_error to the debug facilities

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.

This patch introduces a new debug flag SLAB_PANIC_ON_ERROR, along with its related SLUB-machinery, in order to extend current slub_debug facilites and provide the aforementioned behavior override.

Quoted 10 lines · Rafael Aquini

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.

Quoted 4 lines

This patch introduces a new debug flag SLAB_PANIC_ON_ERROR, along with its related SLUB-machinery, in order to extend current slub_debug facilites and provide the aforementioned behavior override.

Instead of adding those things everywhere. How about adding something like panic_on_taint? Then, you could write specific taint flags you are interested in to that file because slab_bug() will taint it TAINT_BAD_PAGE.

Quoted 15 lines · Qian Cai

Quoted 14 lines · Rafael Aquini

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.

This patch introduces a new debug flag SLAB_PANIC_ON_ERROR, along with its related SLUB-machinery, in order to extend current slub_debug facilites and provide the aforementioned behavior override.

Quoted 2 lines

Instead of adding those things everywhere. How about adding something like panic_on_taint? Then, you could write specific taint flags you are interested in to that file because slab_bug() will taint it TAINT_BAD_PAGE.

It seems like a good idea which also would required "adding things" elsewhere, but doesn't look mutually exclusive with the approach here.

It seems like a good idea which also would required "adding things" elsewhere, but doesn't look mutually exclusive with the approach here.

Quoted 6 lines · Rafael Aquini

It seems like a good idea which also would required "adding things" elsewhere, but doesn't look mutually exclusive with the approach here.

Also, what’s so special about these bad pages here that deserve a crash dump, but not other TAINT_BAD_PAGE places?

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.

This patch introduces a new debug flag SLAB_PANIC_ON_ERROR, along with its related SLUB-machinery, in order to extend current slub_debug facilites and provide the aforementioned behavior override.

Quoted 11 lines · On Fri, 1 May 2020 17:15:40 -0400 Rafael Aquini <[email protected]> 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.

This patch introduces a new debug flag SLAB_PANIC_ON_ERROR, along with its related SLUB-machinery, in order to extend current slub_debug facilites and provide the aforementioned behavior override.

Sees reasonable.

Documentation/vm/slub.rst Possible debug options are:: · line 58

Quoted 8 lines

Documentation/vm/slub.rst +2 -0

@@ -54,6 +54,8 @@ Possible debug options are::
 			caused higher minimum slab orders
 	-		Switch all debugging off (useful if the kernel is
 			configured with CONFIG_SLUB_DEBUG_ON)
+	C		Toggle panic on error (crash) to allow for post-mortem
+			analysis of a coredump taken at the error-spotting time

nit: "toggle" means to switch to the other state. But what we're doing here is to set to the "on" state. This:

Documentation/vm/slub.rst renamed from Documentation/vm/slub.rst~mm-slub-add-panic_on_error-to-the-debug-facilities-fix +2 -2

@@ -49,12 +49,12 @@ Possible debug options are::
 	P		Poisoning (object and padding)
 	U		User tracking (free and alloc)
 	T		Trace (please only use on single slabs)
-	A		Toggle failslab filter mark for the cache
+	A		Enable failslab filter mark for the cache
 	O		Switch debugging off for caches that would have
 			caused higher minimum slab orders
 	-		Switch all debugging off (useful if the kernel is
 			configured with CONFIG_SLUB_DEBUG_ON)
-	C		Toggle panic on error (crash) to allow for post-mortem
+	C		Enable panic on error (crash) to allow for post-mortem
 			analysis of a coredump taken at the error-spotting time
 
 F.e. in order to boot just with sanity checks and red zoning one would specify::

_

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.

Quoted 5 lines · Rafael Aquini

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.

Quoted 12 lines · Christopher Lameter

Quoted 5 lines · Rafael Aquini

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.

Quoted 3 lines

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.