UCAS(9)

🦋 UCAS(9) — atomic memory operations on user-space address

🌸 NAME 🌸

ucas — atomic memory operations on user-space address. okay bestie, this is the Kernel Developer's Manual page for it, and it's giving “kernel meets user space” in the most iconic way. 💅

✨ SYNOPSIS ✨

#include <sys/systm.h>

int
ucas_ptr(volatile void *uptr, void *old, void *new, void *retp);

int
ucas_int(volatile int *uptr, int old, int new, int *retp);

💖 DESCRIPTION 💖

okay so these functions provide compare-and-swap (CAS) functionality on a user-space address. 🔥

aside from the fact that they can be safely used for the kernel to access a user-space address, they're semantically equivalent to atomic_cas(3). no cap.

• uptr — the pointer to the variable. this should be a user-space pointer, bestie.
• old — the value to compare with the variable.
• new — the value to store to the variable.
• retp — the pointer to the memory to store the old value of the variable.

🧚 IMPLEMENTATION NOTES 🧚

the ucas functions are implemented in machine-independent code, but they rely on machine-dependent code to implement optimized primitives, if possible. periodt. 🫶

the basic ucas primitives have the following signatures and are considered private to the implementation — not to be called by consumers of the ucas API, so don't touch, iykyk:

int _ucas_32(volatile uint32_t *uptr, uint32_t old, uint32_t new,
          uint32_t *retp);

int _ucas_64(volatile uint64_t *uptr, uint64_t old, uint64_t new,
          uint64_t *retp);

if a platform is able to provide a CAS operation that meets the following criteria, it should define __HAVE_UCAS_FULL in <machine/types.h> and provide complete machine-dependent implementations of _ucas_32() (and _ucas_64(), if an _LP64 platform):

• can be implemented using either native compare-and-swap operations or load-locked / store-conditional code sequences.
• can be used on uniprocessor and multiprocessor systems.
• can operate across the kernel-userspace boundary.

if __HAVE_UCAS_FULL is not defined, then a generic implementation will be provided by machine-dependent code. this generic implementation is suitable for uniprocessor and multiprocessor systems, but it works on a “least-common denominator” principle. in particular, kernel preemption is disabled during the critical section (which is comprised of ufetch(9) and ustore(9) operations), and the multiprocessor implementation synchronizes with other CPUs using interprocessor interrupts. 😭

if a particular platform wishes to use the generic implementation on uniprocessors but an optimized implementation on multiprocessors, the platform should define __HAVE_UCAS_MP in <machine/types.h> and provide _ucas_32_mp() (and _ucas_64_mp(), if an _LP64 platform). 💅

🦋 RETURN VALUES 🦋

on success, these functions return 0. in that case, the caller can consult the value returned via retp to check the result of the CAS operation. otherwise, these functions return an appropriate errno(9) error code, typically EFAULT. 🫶

🔥 SEE ALSO 🔥

• atomic_cas(3)
• intro(9)

💀 BUGS 💀

conceptually, the retp argument of ucas_ptr() would be of void **. the current prototype is a compromise for usability. so yeah, it's a lil’ compromise, but it's iconic in its own way. 💀

---

💖 this has been the Debian version of UCAS(9), dated March 31, 2019 — mwah, go slay those atomics, bestie! 🎀