get_update_locks_for_mdev(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… get_update_locks_for_mdev β€” the kernel API manual, bestie edition πŸŽ€

okay so picture this: it's a Kernel API Manual page, and the star of the show is get_update_locks_for_mdev. She grabs all the locks you need to dynamically update a KVM guest's APCB β€” and she grabs them in the correct order, because order is literally everything here. periodt. πŸ‘‘


✨ SYNOPSIS ✨

void get_update_locks_for_mdev (struct ap_matrix_mdev *matrix_mdev );

🌸 ARGUMENTS 🌸

  • matrix_mdev β€” a pointer to a struct ap_matrix_mdev object. She's holding the AP configuration data you're gonna use to update a KVM guest's APCB. that's her whole job tbh 🫢

πŸ”₯ DESCRIPTION πŸ”₯

the way this function works is honestly so organized of her. the proper locking order is exactly this, no improvising, no vibes-based reordering:

  1. matrix_dev->guests_lock β€” required to use the KVM pointer to update a KVM guest's APCB.
  2. matrix_mdev->kvm->lock β€” required to update a guest's APCB.
  3. matrix_dev->mdevs_lock β€” required to access data stored in a matrix_mdev.

like, she said "the locks come in a specific order and I'm not negotiating." iconic behavior, honestly. πŸ’…


πŸ¦‹ NOTE πŸ¦‹

lowkey important caveat: if matrix_mdev is NULL, or it's not attached to a KVM guest, then the KVM lock will not be taken. no guest, no lock, no problem. 😌

πŸ‘‘ SEE ALSO πŸ‘‘

the whole friend group, in no particular order (okay, it's in this particular order):


and that's the whole page, bestie πŸ’– this one lives over in ./drivers/s390/crypto, stamped October 2026, and it answers to the name get_update_locks_for_mdev(9). go forth and lock in the right order, ily, mwah 🧚✨

πŸ“¦ where this page comes from