drm_gpuvm_sm_map_exec_lock(9)

📦 version 7.3.1, in nixpkgs unstable

💅 drm_gpuvm_sm_map_exec_lock(9)

okay so bestie, buckle up — this is from the Kernel API Manual, and it's literally the function that does the locking homework before your driver starts messing with the VM. no cap, it's giving "responsible older sibling energy" 🫶

✨ NAME ✨

drm_gpuvm_sm_map_exec_lock — locks the objects touched by a drm_gpuvm_sm_map()

🌸 SYNOPSIS 🌸

int drm_gpuvm_sm_map_exec_lock (struct drm_gpuvm *gpuvm , struct drm_exec *exec , unsigned int num_fences , struct drm_gpuvm_map_req *req );

🎀 ARGUMENTS 🎀

  • gpuvm — the drm_gpuvm that represents the GPU VA space 💖
  • exec — the drm_exec locking context
  • num_fences — for newly mapped objects, the # of fences to reserve
  • req — ptr to drm_gpuvm_map_req struct

🦋 DESCRIPTION 🦋

so what this function actually does: it locks (drm_exec_lock_obj) the objects that are gonna get unmapped/remapped, and it locks and prepares (drm_exec_prepare_object) the objects that are gonna be newly mapped. two-for-one, we love to see it ✨

the expected usage is, and I quote:

vm_bind {
    struct drm_exec exec;

    // IGNORE_DUPLICATES is required, INTERRUPTIBLE_WAIT is recommended:
    drm_exec_init(exec, IGNORE_DUPLICATES | INTERRUPTIBLE_WAIT, 0);

    drm_exec_until_all_locked (exec) {
        for_each_vm_bind_operation {
            switch (op->op) {
            case DRIVER_OP_UNMAP:
                ret = drm_gpuvm_sm_unmap_exec_lock(gpuvm, exec, op->addr, op->range);
                break;
            case DRIVER_OP_MAP:
                ret = drm_gpuvm_sm_map_exec_lock(gpuvm, exec, num_fences, req);
                break;
            }

            drm_exec_retry_on_contention(exec);
            if (ret)
                return ret;
        }
    }
}

the whole point, bestie: this enables all the locking to be performed before the driver even begins modifying the VM. main character scheduling behavior, honestly 👑

and it's safe to do this even in the case of overlapping DRIVER_VM_BIND_OPs, where an earlier op can alter the sequence of steps generated for a later op — because that later altered step will involve the same GEM object(s) you already saw in the earlier locking step. which is, like, the whole flex. for example:

  1. An earlier driver DRIVER_OP_UNMAP op removes the need for a DRM_GPUVA_OP_REMAP/UNMAP step. This is safe because we've already locked the GEM object in the earlier DRIVER_OP_UNMAP op.
  2. An earlier DRIVER_OP_MAP op overlaps with a later DRIVER_OP_MAP/UNMAP op, introducing a DRM_GPUVA_OP_REMAP/UNMAP that wouldn't have been required without the earlier DRIVER_OP_MAP. This is safe because we've already locked the GEM object in the earlier DRIVER_OP_MAP step.

like… it just works. no notes. 🔥

⭐ RETURN ⭐

0 on success, or a negative error code 😭

🌈 SEE ALSO 🌈

grab a snack, this list is long but every single one of them made it 💅

and that's the page, bestie 🧚 this little baddie lives in ./drivers/gpu/drm and it was dated October 2026 — so go forth, lock responsibly, and slay 💜🍓

📦 where this page comes from