WITNESS(4)

💅 WITNESS(4) — the lock validation facility, bestie edition 🎀

okay so this is a kernel interfaces manual page, and honestly? witness is the most main-character debugging tool in the whole kernel. let me tell you everything 👑

---

✨ SYNOPSIS ✨

options WITNESS
options WITNESS_COUNT
options WITNESS_KDB
options WITNESS_NO_VNODE
options WITNESS_SKIPSPIN

like, that's the whole vibe right there. five options lines and you're in 🫶

---

🌸 DESCRIPTION 🌸

okay so the witness module is literally the lock babysitter. it keeps track of the locks acquired and released by each thread. it also keeps track of the order in which locks are acquired with respect to each other. two lists, one job 💅

every single time a lock is acquired, witness uses these two lists to verify that a lock is not being acquired in the wrong order. and if a lock order violation is detected? a message is output to the kernel console or log detailing the locks involved and the locations in question. it's giving receipts, fr fr 📋

witness can also be configured to drop into the kernel debugger when an order violation occurs. iconic behavior honestly.

the witness code also checks various other conditions, like:

• verifying that one does not recurse on a non-recursive lock
• verifying that one does not attempt an upgrade on a shared lock held by another thread

and if any of these checks fail, then the kernel will panic. 😭 no cap. not a vibe, but that's the deal.

---

🧮 the WITNESS_COUNT situation

the WITNESS_COUNT kernel option controls the maximum number of witness entries that are tracked in the kernel.

• the maximum number of entries can be queried via the debug.witness.witness_count sysctl
• it can also be set from the loader(8) via the debug.witness.witness_count environment variable

slay, two ways to do the thing ✨

---

🦋 WITNESS_NO_VNODE — the vnode peace treaty

the WITNESS_NO_VNODE kernel option tells witness to ignore locking issues between vnode(9) objects. like, they're on a break. let them live 🙈

---

⭐ the kdb flag — how do we get into the debugger

the flag that controls whether or not the kernel debugger is entered when a lock order violation is detected can be set in a variety of ways:

• by default, the flag is off
• but if the WITNESS_KDB kernel option is specified, then the flag will default to on
• it can also be set from the loader(8) via the debug.witness.kdb environment variable
• or after the kernel has booted via the debug.witness.kdb sysctl

if the flag is set to zero, then the debugger will not be entered. if the flag is non-zero, then the debugger will be entered. that's it, that's the rule 💀

---

🌀 WITNESS_SKIPSPIN — spin mutexes can chill

the witness code can also be configured to skip all checks on spin mutexes.

• by default, this flag defaults to off
• but it can be turned on by specifying the WITNESS_SKIPSPIN kernel option
• the flag can also be set via the loader(8) environment variable debug.witness.skipspin
• if the variable is set to a non-zero value, then spin mutexes are skipped

and once the kernel has booted, the status of this flag can be examined but not set via the read-only sysctl debug.witness.skipspin. read-only, bestie. look, don't touch 🚫

---

👀 debug.witness.watch — how involved is witness, exactly

the sysctl debug.witness.watch specifies the level of witness involvement in the system. the values:

• 1 — specifies that witness is enabled
• 0 — specifies that witness is disabled, but that can be enabled again. this will maintain a small amount of overhead in the system
• -1 — specifies that witness is disabled permanently and cannot be enabled again

the sysctl debug.witness.watch can be set via loader(8). periodt 🌈

---

📢 debug.witness.output_channel — where do the warnings go

the sysctl debug.witness.output_channel specifies the output channel used to display warnings emitted by witness. the possible values are:

• 'console' — indicating that warnings are to be printed to the system console
• 'log' — indicating that warnings are to be logged via log(9)
• 'none'

this sysctl can be set via loader(8). pick your aesthetic 💖

---

🖥️ the ddb commands — bonus content, iykyk

the witness code also provides three extra ddb(4) commands if both witness and ddb(4) are compiled into the kernel:

• show locks [thread] — outputs the list of locks held by a thread to the kernel console along with the filename and line number at which each lock was last acquired by the thread. the optional thread argument may be either a TID, PID, or pointer to a thread structure. if thread is not specified, then the locks held by the current thread are displayed. 💅
• show all locks — outputs the list of locks held by all threads in the system to the kernel console. everybody's locks, all at once, it's giving group chat screenshot 🫶
• show witness — dumps the current order list to the kernel console. the code first displays the lock order tree for all of the sleep locks. then it displays the lock order tree for all of the spin locks. finally, it displays a list of locks that have not yet been acquired. three courses, chef's kiss 👑

---

🔗 SEE ALSO 🔗

ddb(4), loader(8), sysctl(8), mutex(9)

go read them, bestie, they're literally all connected 🧚

---

📜 HISTORY 📜

the witness code first appeared in BSD/OS 5.0 and was imported from there into FreeBSD 5.0. a whole journey, honestly 💜

---

and that's the page!! this one's from the Debian crew, dated March 5, 2025, and yes the manual name is right there in the title: WITNESS(4) 🎀✨ go forth and never violate a lock order again, ily 🫶💖