get_update_locks_by_apqn(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… get_update_locks_by_apqn(9) β€” kernel API manual, bestie edition

okay so first things first, this is a page from the Kernel API Manual, section 9 (the kernel API section, iykyk), and the star of the show is get_update_locks_by_apqn. buckle up πŸŽ€


✨ NAME ✨

get_update_locks_by_apqn β€” find the mdev that an APQN is assigned to, and grab all the locks you need before updating the APCB of the KVM guest that mdev is attached to. literally that's the whole job 🫢


🌸 SYNOPSIS 🌸

struct ap_matrix_mdev * get_update_locks_by_apqn (int apqn );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • apqn β€” the APQN of a queue device. that's it, that's the argument πŸ’…

πŸ‘‘ DESCRIPTION πŸ‘‘

ok so the proper locking order β€” and yes, order matters, do not freestyle this β€” is:

  1. matrix_dev->guests_lock: you need this one to use the KVM pointer and update a KVM guest's APCB.
  2. matrix_mdev->kvm->lock: you need this one to update a guest's APCB.
  3. matrix_dev->mdevs_lock: you need this one to access data stored in a matrix_mdev.

three locks, one very specific sequence, no cap πŸ”₯


πŸ™ˆ NOTE πŸ™ˆ

careful bestie: if apqn is not assigned to a matrix_mdev, then matrix_mdev->kvm->lock will not be taken. so don't go assuming you're holding it β€” check first, fr fr πŸ’€

⭐ RETURN ⭐

it gives you back the ap_matrix_mdev object that apqn is assigned to β€” or NULL if apqn isn't assigned to an ap_matrix_mdev at all. no object, no locks, no drama 🌈


πŸ’– SEE ALSO πŸ’–

the whole friend group πŸ‘‡


and that's the page!! this lil icon came from ./drivers/s390/crypto (that's the source, bestie πŸ“) and it's dated October 2026, filed under get_update_locks_by_apqn(9). go forth and lock in the right order, mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from