nbcon_contex...ire_handover(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… nbcon_contex...ire_handover(9) β€” like, the handover edition

okay bestie so this is a page straight out of the Kernel API Manual β€” we're talking nbcon_contex...ire_handover(9) and it's genuinely such a serve, let me tell you everything πŸŽ€


✨ NAME ✨

nbcon_context_try_acquire_handover β€” try to acquire via handover, no cap 🫢


🌸 SYNOPSIS 🌸

int nbcon_context_try_acquire_handover (struct nbcon_context *ctxt ,
       struct nbcon_state *cur );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • ctxt β€” the context of the caller, aka you, main character πŸ’…
  • cur β€” the current console state, the vibe check snapshot of the moment ✨

🧚 DESCRIPTION 🧚

so here's the tea, bestie β€” you can only call this function when two things are true at once:

  • your context has higher priority than the current owner, and
  • the console is in an unsafe state.

That's literally the exact situation you're in when nbcon_context_try_acquire_direct returns -EBUSY. so if you got -EBUSY from direct acquire, hi, this page is for you πŸ’–

What it does is kinda iconic actually: it sets the "req_prio" field so the current owner knows you're out here requesting the console. then it waits. and waits. until one of these happens:

  1. the current owner releases the console ✨
  2. an even higher context takes over the request πŸ‘‘
  3. the timeout expires 😭

and the current owner? they check the "req_prio" field on the way out of the unsafe region and then release the console. important detail β€” they do not touch the "req_prio" field, so the console stays reserved for the waiter. respectful. we love to see it 🫢


πŸ’€ Errors (the moments things go sideways)

  • -EPERM β€” a panic is in progress and this is not the panic CPU. or a higher priority context has taken over the console or the handover request. like, it's not your turn, babe πŸ™ˆ
  • -EBUSY β€” the current owner is on the same CPU, so the hand shake could not work. or the current owner is not willing to wait (zero timeout). or the console does not enter the safe state before the timeout passed. the caller might still use the unsafe hostile takeover when allowed β€” dramatic, honestly πŸ”₯
  • -EAGAIN β€” cur has changed when creating the handover request. the caller should retry with direct acquire. just a little redo, no biggie πŸŒ€

🌈 RETURN 🌈

0 on success, slay πŸŽ‰ otherwise an error code on failure. also, cur gets updated to the latest state when it failed to modify it β€” so like, it's keeping you informed πŸ’œ


⭐ SEE ALSO ⭐

Kernel file ./kernel/printk/nbcon.c β€” and the whole friend group:


fr fr bestie, read the -EBUSY bit twice β€” the unsafe hostile takeover is a real thing that exists and you should know about it before you go touching it πŸ’€

and that's the whole page!! mwah πŸ’‹ this came to you from the kernel source tree at ./kernel/printk, dated October 2026, and the page itself is nbcon_contex...ire_handover(9) β€” go forth and hand over those consoles responsibly, queen πŸ‘‘βœ¨

πŸ“¦ where this page comes from