drm_panic_trylock(9)

💖 drm_panic_trylock(9) — from the Kernel API Manual, bestie 💖

okay so picture this: it's a kernel panic, everything is on fire 🔥, and you need to print something to the screen right now. This little function, drm_panic_trylock(9), is your girl. She's the one who tries to get you into the panic printing critical section. No cap.

---

✨ SYNOPSIS ✨

drm_panic_trylock (dev , flags );

---

🎀 ARGUMENTS 🎀

• dev — a struct drm_device. that's your device, bestie 🫶
• flags — unsigned long irq flags. you literally have to pass these to the unlock counterpart, so don't lose them, iykyk 💅

---

🌸 DESCRIPTION 🌸

So any panic printing code must call this function. like, mandatory, periodt. And if the trylock fails? You abort the whole panic printing attempt. no arguments, no second chances 💀

While you're holding the panic lock, the panic printing code is allowed to assume the following, and honestly? it's giving main character energy:

• anything protected by drm_panic_lock and drm_panic_unlock pairs is safe to access. go off 👑
• furthermore, the panic printing code only registers in drm_dev_unregister and gets removed in drm_dev_unregister. this lets the panic code safely access any state that's invariant in between those two function calls — like the list of planes drm_mode_config.plane_list, or most of the struct drm_plane structure. iconic.

And specifically, thanks to the protection around plane updates in drm_atomic_helper_swap_state, you get these extra guarantees too:

• it is safe to dereference the drm_plane.state pointer ✨
• anything in struct drm_plane_state — or your driver's subclass of it — that stays invariant after the atomic check code has finished is safe to access. specifically, this includes the reference counted pointers to framebuffer and buffer objects 🦋
• anything set up by drm_plane_helper_funcs.fb_prepare and cleaned up by drm_plane_helper_funcs.fb_cleanup is safe to access, as long as it stays invariant between those two calls. this also means that for drivers using dynamic buffer management the framebuffer is pinned, and therefore all relevant datastructures can be accessed without taking any further locks (which would be impossible in panic context anyway). slay 🎀
• importantly — software and hardware state set up by drm_plane_helper_funcs.begin_fb_access and drm_plane_helper_funcs.end_fb_access is not safe to access. nope. do not. 🚫

⚠️ drivers must not make any assumptions about the actual state of the hardware, unless they explicitly protected that hardware access with drm_panic_lock and drm_panic_unlock. read it again. internalize it. fr fr.

---

⭐ RETURN ⭐

• 0 when failing to acquire the raw spinlock
• nonzero on success

(yes, that's inverted from what your brain wants it to be — 0 means it failed. lowkey cursed but that's the deal 🙈)

---

🌈 SEE ALSO 🌈

Kernel file ./include/drm/drm_panic.h — plus struct drm_scanout_buffer(9), drm_panic_lock(9), and drm_panic_unlock(9). go read the whole squad 🫶

---

okay that's the whole page, bestie 💜 this one lives in ./include/drm, dated October 2026, and it's filed under drm_panic_trylock(9) — now go forth and panic-print responsibly, mwah 🧚💖