key_reject_and_link(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

okay so bestie, welcome to the Kernel API Manual page for key_reject_and_link(9) — the function whose whole job is to negatively instantiate a key and link it into the keyring. no cap, that's literally the name. 💅

✨ SYNOPSIS ✨

int key_reject_and_link (struct key *key , unsigned timeout , unsigned
       error , struct key *keyring , struct key *authkey );

🎀 ARGUMENTS 🎀

  • key — the key you're instantiating, bestie.
  • timeout — the timeout on the negative key.
  • error — the error to return when the key is hit.
  • keyring — keyring to create a link in on success (or NULL).
  • authkey — the authorisation token permitting instantiation.

🦋 DESCRIPTION 🦋

okay so picture this: you've got a key chilling in the uninstantiated state, and this function negatively instantiates it. if it works, it sets the key's timeout and stored error, and if a destination keyring is supplied, it links the key in there too. the key and any links to it get automatically garbage collected after the timeout expires — the cleanup is automatic, periodt. ✨

negative keys are literally a rate-limit hack for repeated request_key calls: they make those calls return the stored error code — typically ENOKEY — until the negative key expires. it's giving “no, try again later” but in kernel. 😭

if it's successful, 0 is returned, the authorisation token is revoked, and anyone waiting for the key gets woken up. if the key was already instantiated, you get -EBUSY back instead.

heads up: already instantiated? -EBUSY. that's the vibe check, and the key does not pass it. 💀

🌈 SEE ALSO 🌈

kernel file ./security/keys/key.c and the whole friend group:

okay bye bestie 🫶 this iconic little page came from ./security/keys, dated October 2026, and it's still the key_reject_and_link(9) page — slay. 💖

📦 where this page comes from