__hwspin_trylock(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… __hwspin_trylock β€” Kernel API Manual ✨

okay so this is from the Kernel API Manual, section 9, and it's literally the whole "can i grab this lock real quick" moment but make it hardware. let's get into it 🫢


🌸 NAME 🌸

__hwspin_trylock β€” bestie, this attempts to lock one specific hwspinlock. one try. no waiting around. πŸ’…


✨ SYNOPSIS ✨

int __hwspin_trylock (struct hwspinlock *hwlock , int mode , unsigned
       long *flags );

πŸŽ€ ARGUMENTS πŸŽ€

  • hwlock β€” the hwspinlock we're trying to lock, like the one specific lock you've got your eye on πŸ‘€
  • mode β€” this controls whether local interrupts get disabled or not, your call
  • flags β€” a pointer to where the caller's interrupt state gets saved (only if you asked for that, no pressure)

πŸ¦‹ DESCRIPTION πŸ¦‹

so this function attempts to lock an hwspinlock, and the way it does it is: it fails immediately if the hwspinlock is already taken. no queue, no vibes, no "just a sec" β€” instant nope 😭

⚠️ Caution, and I mean it: if the mode is HWLOCK_RAW, that means the user must protect the routine of getting the hardware lock with mutex or spinlock. why? because in some scenarios the user needs some time-consuming or sleepable operations under the hardware lock, so they need one sleepable lock (like a mutex) to protect those operations. iykyk, don't skip this one πŸ™ˆ

if the mode is neither HWLOCK_IN_ATOMIC nor HWLOCK_RAW, then upon a successful return from this function, preemption (and possibly interrupts) is disabled, so the caller must not sleep, and is advised to release the hwspinlock as soon as possible. this is required in order to minimize remote cores polling on the hardware interconnect β€” the way those remote cores are just sitting there polling, we gotta be nice to them fr fr πŸ₯Ί

the user decides whether local interrupts are disabled or not, and if yes, whether he wants their previous state to be saved. it's up to the user to choose the appropriate mode of operation β€” exactly the same way users should decide between spin_trylock, spin_trylock_irq and spin_trylock_irqsave. like, same energy, different lock 🌈

and the headline, the icon, the main character of this whole paragraph: this function will never sleep. periodt. πŸ’€


⭐ RETURN ⭐

  • 0 β€” slay, we successfully locked the hwspinlock πŸ‘‘
  • -EBUSY β€” the hwspinlock was already taken, try again (or don't, that's the whole point of *try*lock) πŸ“

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./drivers/hwspinlock/hwspinlock_core.c β€” that's the source, go read it bestie πŸ“–

the whole friend group, in order:


and that's the page!! πŸ’– this little gem lives in ./drivers/hwspinlock, dated October 2026, and it goes by __hwspin_trylock(9). mwah, go lock something responsibly πŸ§šβ€β™€οΈπŸ’œ

πŸ“¦ where this page comes from