Documentation/admin-guide/mm/slab.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/mm/slab.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/mm/slab.rst
Extension
.rst
Size
17944 bytes
Lines
470
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

[<c0183ba7>] vfs_write+0xd1/0x15a
   [<c01841d7>] sys_write+0x3d/0x72
   [<c0104112>] sysenter_past_esp+0x5f/0x99
   [<b7f7b410>] 0xb7f7b410
   =======================

 FIX kmalloc-8: Restoring Redzone 0xc90f6d28-0xc90f6d2b=0xcc

If SLUB encounters a corrupted object (full detection requires the kernel
to be booted with slab_debug) then the following output will be dumped
into the syslog:

1. Description of the problem encountered

   This will be a message in the system log starting with::

     ===============================================
     BUG <slab cache affected>: <What went wrong>
     -----------------------------------------------

     INFO: <corruption start>-<corruption_end> <more info>
     INFO: Slab <address> <slab information>
     INFO: Object <address> <object information>
     INFO: Allocated in <kernel function> age=<jiffies since alloc> cpu=<allocated by
	cpu> pid=<pid of the process>
     INFO: Freed in <kernel function> age=<jiffies since free> cpu=<freed by cpu>
	pid=<pid of the process>

   (Object allocation / free information is only available if SLAB_STORE_USER is
   set for the slab. slab_debug sets that option)

2. The object contents if an object was involved.

   Various types of lines can follow the BUG SLUB line:

   Bytes b4 <address> : <bytes>
	Shows a few bytes before the object where the problem was detected.
	Can be useful if the corruption does not stop with the start of the
	object.

   Object <address> : <bytes>
	The bytes of the object. If the object is inactive then the bytes
	typically contain poison values. Any non-poison value shows a
	corruption by a write after free.

   Redzone <address> : <bytes>
	The Redzone following the object. The Redzone is used to detect
	writes after the object. All bytes should always have the same
	value. If there is any deviation then it is due to a write after
	the object boundary.

	(Redzone information is only available if SLAB_RED_ZONE is set.
	slab_debug sets that option)

   Padding <address> : <bytes>
	Unused data to fill up the space in order to get the next object
	properly aligned. In the debug case we make sure that there are
	at least 4 bytes of padding. This allows the detection of writes
	before the object.

3. A stackdump

   The stackdump describes the location where the error was detected. The cause
   of the corruption is may be more likely found by looking at the function that
   allocated or freed the object.

4. Report on how the problem was dealt with in order to ensure the continued
   operation of the system.

   These are messages in the system log beginning with::

Annotation

Implementation Notes