MAKEDUMPFILE.CONF(5)

💖 MAKEDUMPFILE.CONF(5) 💖

Linux System Administrator's Manual — ok so this is the makedumpfile.conf page, bestie, and yes it's a manual page manual, section 5, we're doing this 🫶

---

✨ NAME ✨

makedumpfile.conf — the filter configuration file for makedumpfile(8). that's it that's the name, short and iconic 👑

---

🌸 DESCRIPTION 🌸

okay so makedumpfile.conf is literally the configuration file for the makedumpfile tool. no cap.

This file is where you keep your erase commands — the ones that filter out whatever kernel data you don't want, straight out of the vmcore, while your DUMPFILE is being created by the makedumpfile tool. it's giving ✨ selective deletion ✨

Here's the vibe: makedumpfile reads your filter config, and after it processes the filter commands it builds up a whole list of memory addresses and their sizes. Then — and this is the part that's lowkey metal — every memory location that needs to be filtered out gets poisoned with the character X (that's 58 in Hex). poisoned!! with an X!! 💀

---

🦋 FILE FORMAT 🦋

The file is made of module sections, and those sections are where your filter commands live. A section starts with the name of the section wrapped in square brackets, and it keeps going until the next section starts. simple as that, bestie 💅

"["<ModuleName>"]"
<FilterCommands>

where:

• "[" — is the character [
• "]" — is the character ]

and then we got our two little placeholders, lemme introduce them:

• <ModuleName> — this is either 'vmlinux' or the name of a Linux kernel module. yes, either/or, pick your fighter 🌈
• <FilterCommands> — a list of one or more filter commands, all described over in the FILTER COMMANDS section of this very manual page. go read it, i'll wait 🎀

---

💜 the section name situation 💜

So the section name tells you which kernel module name (and yes that includes vmlinux) the symbols in the following erase commands belong to. like, whose symbols are these? that's what the section name is answering. so helpful of it, honestly 🫶

And here's the cute little default: the unnamed section defaults to the [vmlinux] section. but — and this is the slay part — a user can also explicitly define the [vmlinux] section if they want. your choice, bestie ✨

These sections are what help the makedumpfile tool pick the right kernel or module debuginfo file before it processes the erase commands that come after. so thoughtful. so organized. main character energy fr fr 👑

Now, before it actually selects that appropriate debuginfo file, the module name gets validated against the loaded modules from the vmcore. vibe check time 🔥

• If no match is found — the section gets ignored, and makedumpfile skips on over to the next module section. bye bestie, not you 🙈
• If a match is found — makedumpfile will try to load the corresponding module debuginfo file. yay!
  • And if that module debuginfo is not available? then makedumpfile skips the section with a warning message. sad but it moves on, that's the growth mindset 💅

ngl, "skips with a warning" is doing a lot of heavy lifting here — but that's exactly what it does, so don't be shocked when you see the warning pop up 😭

---

✨ FILTER COMMANDS ✨

filter command

Okay bestie, a filter command is either an erase command or a loop construct. That's the whole vibe check. And important: every single erase command and loop construct has to start on a new line — no sneaking them in mid-line. Each filter command describes data in the dump that's getting erased. The syntax is:

<EraseCommands>|<LoopConstruct>

where:

• <EraseCommands> — bestie this is literally the erase command subsection down below, go read it 💖
• <LoopConstruct> — and this one is the Loop construct subsection, also down below 🌸

---

erase command

This one erases a specified size of kernel data that's referred to by a specified kernel/module symbol, or by one of its member components. Syntax goes like this:

erase <Symbol>[.member[...]] [size <SizeValue>[K|M]]
erase <Symbol>[.member[...]] [size <SizeSymbol>]
erase <Symbol>[.member[...]] [nullify]

where:

• <Symbol> — a kernel or module symbol (variable) name that's part of the global symbols in /proc/kallsyms. 👑
• <SizeValue> — a positive integer value, being the size of the data to be erased, in bytes. The suffixes 'K' and 'M' can be used to specify kilobytes and megabytes respectively, where K means 1024 bytes and M means 1024 ^ 2 = 1048576 bytes. And ngl, those suffixes are not case sensitive — live your truth. ✨
• <SizeSymbol> — a simple expression of the form <Symbol>[.member[...]] that denotes a symbol which contains a positive integer value as the size of the data to be erased, in bytes.
• <Symbol>[.member[...]] — a simple expression that results in either a global kernel symbol name or its member components. This expression always uses the '.' operator to specify the member component of a kernel symbol or of its member — doesn't matter whether it's of pointer type or not, the . is the moment, periodt.
• member[...] — member, or component of a member, in <Symbol>.

The erase command takes two arguments: 1. the kernel symbol name or its member components, and 2. the size of the data referred by argument (1), OR the nullify keyword. That second argument — size OR nullify — is optional. The unit for size value is in bytes. If the size option isn't specified, then the size of the first argument gets determined according to its data type using dwarf info from the debuginfo file. In the case of 'char *' data type, the length of the string pointed to by the 'char *' pointer is determined with an upper limit of 1024. And the size can be specified in two forms: 1. an integer value as explained above (<SizeValue>), and 2. a simple expression in the form of <Symbol>[.member[...]]] that results in a base type (integer) variable.

Heads up bestie 🫶 — if the specified <Symbol> is of type 'void *', then you need to provide either the size or the nullify option, otherwise the erase command literally will not have any effect. Not a single byte. Nothing. 💀

The nullify option only works if the specified <Symbol> is a pointer. Instead of erasing the data pointed to by the specified pointer, nullify erases the pointer value itself and sets it to '0' (NULL). And please note: by nullifying the pointer values you may affect the debug ability of the created DUMPFILE. 😭 So use the nullify option only when the size of the data to be erased isn't known — e.g. data pointed to by 'void *'.

Let's look at the makedumpfile.conf file from the example below, which was configured to erase desired kernel data from the kernel module with name mymodule. At line 1 and line 3, the user didn't specify the size option while erasing the 'array_var' and 'mystruct1.name' symbols. Instead the user is depending on makedumpfile to automatically determine the sizes to be erased — that's 100 bytes for 'array_var' and 11 bytes for 'mystruct1.name'. At line 2, while erasing the 'mystruct1.buffer' member, the user specified the size value 25 against the actual size of 50. In this case the user-specified size takes the precedence and makedumpfile erases only 25 bytes from ´mystruct1.buffer'. At line 4, the size of the data pointed to by the void * pointer 'mystruct1.addr1' is unknown. Hence the nullify option has been specified to reset the pointer value to NULL. At line 5, the ´mystruct2.addr_size' is specified as the size argument to determine the size of the data pointed to by the void * pointer 'mystruct2.addr'.

Example:

Assuming the following piece of code is from the kernel module 'mymodule':

struct s1 {
     char *name;
     void *addr1;
     void *addr2;
     char buffer[50];
};
struct s2 {
     void *addr;
     long addr_size;
};

/* Global symbols */
char array_var[100];
struct s1 mystruct1;
struct s2 *mystruct2;

int foo()
{
     ...
     s1.name = "Hello World";
     ...
}

makedumpfile.conf:

[mymodule]
erase array_var
erase mystruct1.buffer size 25
erase mystruct1.name
erase mystruct1.addr1 nullify
# Assuming addr2 points to 1024 bytes
erase mystruct1.addr2 size 1K
erase mystruct2.addr size mystruct2.addr_size
EOF

---

Loop construct

A Loop construct lets you traverse linked list or array elements and erase the data contents referred to by each element. Iconic behaviour honestly.

for <id> in {<ArrayVar> |
             <StructVar> via <NextMember> |
             <ListHeadVar> within <StructName>:<ListHeadMember>}
     erase <id>[.MemberExpression] [size <SizeExpression>|nullify]
     [erase <id>...]
     [...]
endfor

where:

• <id> — an arbitrary name used to temporarily point to elements of the list. This is also called the iteration variable. 🎀
• <ArrayVar> — a simple expression in the form of <Symbol>[.member[...]] that results in an array variable.
• <StructVar> — a simple expression in the form of <Symbol>[.member[...]] that results in a variable that points to a structure.
• <NextMember> — member within <StructVar> that points to an object of the same type as <StructVar>.
• <ListHeadVar> — a simple expression in the form of <Symbol>[.member[...]] that results in a variable of type struct list_head.
• <StructName> — name of the structure type that can be traversed using the HEAD variable <ListHeadVar> and that contains a member named <ListHeadMember>.
• <ListHeadMember> — name of a member in <StructName>, of type struct list_head.
• <MemberExpression> — a simple expression in the form of [.member[...]] to specify a member or component of an element in <ArrayVar>, <StructVar> or <StructName>.
• <SizeExpression> — size value in the form of <SizeValue>, <id>[.MemberExpression] or <Symbol>[.member[...]].

The for loop construct allows iterating on a list of elements in an array or linked lists. Each element in the list gets assigned to the iteration variable <id>. The type of the iteration variable is determined by that of the list elements. The entry specified after the 'in' terminal is called the LIST entry. The LIST entry can be an array variable, a structure variable/pointer, or a struct list_head type variable. The set of erase commands specified between for and endfor will be executed for each element in the LIST entry. 💅

If the LIST entry specified is an array variable, then the loop will be executed for each array element. The size of the array gets determined by using dwarf information.

If the LIST entry specified is a structure variable/pointer, then a traversal member (<NextMember>) must be specified using the 'via' terminal. The for loop will continue until the value of the traversal member is NULL, or matches with the address of the first node <StructVar> if it's a circular linked list. 🌀

If the LIST entry is specified using a struct list_head type variable, then the within terminal must be used to specify the structure name <StructName> that surrounds it, along with the struct list_head type member after the ':' which is part of the linked list. In the erase statement, <id> then denotes the structure that the list_head is contained in (ELEMENT_OF).

The example below illustrates how to use the loop construct for traversing an Array, a linked list via a next member, and a list_head. Slay.

Example:

Assuming the following piece of code is from the kernel module 'mymodule':

struct s1 {
     struct *next;
     struct list_head list;
     char private[100];
     void *key;
     long key_size;
};

/* Global symbols */
struct s1 mystruct1;
static LIST_HEAD(s1_list_head);
struct s1 myarray[100];

void foo()
{
     struct s1 *s1_ptr;
     ...
     ...
     s1_ptr = malloc(...);
     ...
     ...
     list_add(&s1_ptr->list, &s1_list_head);
     ...
}

makedumpfile.conf:

[mymodule]
# erase private fields from list starting with mystruct1 connected via
# 'next' member:
for mys1 in mystruct1 via next
     erase mys1.private
     erase mys1.key size mys1.key_size
endfor

# erase private fields from list starting with list_head variable
# s1_list_head.
for mys1 in s1_list_head.next within s1:list
     erase mys1.private
     erase mys1.key size mys1.key_size
endfor

# erase private fields from all elements of the array myarray:
for mys1 in myarray
     erase mys1.private
     erase mys1.key size mys1.key_size
endfor
EOF

In the above example, the first for construct traverses the linked list through a specified structure variable mystruct1 of type struct s1. The linked list can be traversed using the 'next' member of mystruct1. Hence a via terminal has been used to specify the traversal member name 'next'.

The second for construct traverses the linked list through a specified struct list_head variable s1_list_head.next. The global symbol s1_list_head is a start address of the linked list, and its next member points to the address of the struct list_head type member 'list' from struct s1. Hence a within terminal is used to specify the structure name 's1' that can be traversed using the s1_list_head.next variable, along with the name of the struct list_head type member 'list' which is part of the linked list that starts from the s1_list_head global symbol.

The third for construct traverses the array elements specified through an array variable myarray.

---

🌈 SEE ALSO 🌈

• makedumpfile(8) — go read the big one, bestie, it's the main character 💖

---

And that's a wrap on MAKEDUMPFILE.CONF(5)! 🎀 This gorgeous thing lives in the Linux System Administrator's Manual, it's makedumpfile v1.7.9, and it's dated 20 Apr 2026. Go forth and filter those dumps responsibly, no cap. 🦋✨👑