DRM_MODESET_LOCK_ALL_END(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… DRM_MODESET_LOCK_ALL_END(9) β€” like, the Kernel API Manual bestie ✨

okay so this is DRM_MODESET_LOCK_ALL_END from the Kernel API Manual, and honestly? she's the cleanup queen we all need. πŸŽ€


🌸 NAME 🌸

DRM_MODESET_LOCK_ALL_END β€” the helper that releases and cleans up your modeset locks. she tidies up after the party. iconic behaviour, no cap. 🧹✨


πŸ¦‹ SYNOPSIS πŸ¦‹

DRM_MODESET_LOCK_ALL_END (dev , ctx , ret );

πŸ’– ARGUMENTS πŸ’–

  • dev β€” your drm device. the main character of the operation tbh. πŸ–₯️
  • ctx β€” the local modeset acquire context. heads up bestie: it will be dereferenced. πŸ™ˆ
  • ret β€” your local ret/err/etc variable, there to track the error status and keep you honest. πŸ’€

✨ DESCRIPTION ✨

so this is literally the other side of DRM_MODESET_LOCK_ALL_BEGIN. they're a matching set, iykyk. 🫢

it will bounce back to BEGIN if ret is -EDEADLK. yes, it goes back. it's giving boomerang energy. πŸͺƒ

⚠️ ok important: you must use the same ret variable for begin and end. like, the same one. this is not a drill. it's so deadlock conditions get handled properly, and skipping it is lowkey a bad time. 😭

πŸ”₯ RETURN πŸ”₯

ret will be untouched unless it's -EDEADLK on entry. so basically:

  • if you successfully acquire the locks, ret stays whatever your code sets it to. slay. πŸ‘‘
  • if there's a deadlock or other failure with acquire or backoff, ret gets set to that failure. πŸ’€

in both of those failure cases, the code between BEGIN/END will not be run β€” so the failure is just reflecting that you couldn't grab the locks. sad but true. 🌈


🌟 SEE ALSO 🌟


πŸ¦„ that's the whole page, bestie β€” brought to you from ./include/drm, October 2026 edition. go forth and release those locks responsibly. periodt. πŸ’œπŸŽ€

πŸ“¦ where this page comes from