drm_modeset_lock(9)

📦 version 7.3.1, in nixpkgs unstable

💅 drm_modeset_lock(9)

okay so bestie, welcome to the Kernel API Manual — this is the page for drm_modeset_lock, and honestly? it's giving "tiny function, big consequences." let's get into it 🎀

✨ NAME ✨

drm_modeset_lock — take modeset lock 🔒

🦋 SYNOPSIS 🦋

int drm_modeset_lock (struct drm_modeset_lock *lock , struct
drm_modeset_acquire_ctx *ctx );

🌸 ARGUMENTS 🌸

  • lock — the lock to take. that's her. that's the one you're grabbing 💅
  • ctx — the acquire ctx. yes, it matters whether this is NULL or not, keep reading bestie 😭

👑 DESCRIPTION 👑

so if ctx is not NULL, then its ww acquire context gets used, and the lock will be tracked by that context — meaning it can be released later by calling drm_modeset_drop_locks. cute, organized, accountable. we love a tracked lock ✨

now the important part: if -EDEADLK gets returned, that means a deadlock scenario has been detected. and like... it is an error to attempt to take any more locks without first calling drm_modeset_backoff. don't push your luck, bestie 💀

🚨 fr fr: -EDEADLK means back off FIRST. no taking more locks until you've called drm_modeset_backoff. no cap.

if ctx is not NULL and it was initialized with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then this function will fail with -ERESTARTSYS when interrupted. so like, it can be interrupted, and it will tell you about it 🙈

and if ctx is NULL? then the function call behaves like a normal, uninterruptible non-nesting mutex_lock call. plain. simple. no context, no tracking, no interruptions. she's on her own main character energy 🧚

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/drm_modeset_lock.c

and that's the page!! 🫶 this one came from ./drivers/gpu/drm, dated October 2026, and the whole thing is filed under drm_modeset_lock(9) — stan a well-documented lock, honestly 👑💖

📦 where this page comes from