ib_umem_get_attr_or_va(9)

📦 version 7.3.1, in nixpkgs unstable

💖 ib_umem_get_attr_or_va — the Kernel API Manual, bestie edition 💖

okay so this one lives in the Kernel API Manual (ib_umem_get_attr_or_va(9)) and it's basically the chill friend of ib_umem_get_attr that will also pin your addr/size when nobody handed it a per-command UMEM attribute. sit down, grab a boba, we're doing this ✨

✨ SYNOPSIS ✨

struct ib_umem * ib_umem_get_attr_or_va (struct ib_device *device ,
const struct uverbs_attr_bundle *attrs , u16 attr_id , u64 addr , size_t
size , int access );

🎀 ARGUMENTS 🎀

  • device — your IB device. the main character of the operation fr.
  • attrs — the uverbs attribute bundle. heads up: this one may be NULL. no cap.
  • attr_id — the per-command UMEM attribute id. this is the one we go looking for first 🕵️‍♀️
  • addr — the UHW user VA. we only reach for this when no per-command attribute matched, iykyk.
  • size — and here's the ✨double life✨: on the attr / legacy paths it's the minimum required umem length validated post-pin; on the VA fallback path it's the length to pin. two jobs, one parameter, she's booked and busy 💅
  • access — the IB access flags. slay.

🦋 DESCRIPTION 🦋

okay so it's literally like ib_umem_get_attr, except when no per-command UMEM attribute is supplied, it goes ahead and pins addr/size itself. iconic behavior tbh 🫶

IMPORTANT: size is always consumed. like, always always. on the attr / legacy paths it's used as the post-pin minimum-length check; on the VA fallback path it's the length to pin. so callers MUST pass a meaningful, validated value — even when they fully expect an attribute-supplied buffer to be the one that gets used. do not be cute and pass garbage, bestie 😭

so here's the tea on size 🍓: every in-tree caller passes the same value for the two roles of size, and that's only because no driver today distinguishes a user-passed buffer length from a driver-computed minimum. that's not a flex, that's just how it is rn.

and the drivers that currently accept a user-supplied length without cross-checking it against a driver minimum? let's name names 💀 — vmw_pvrdma CQ/QP/SRQ, qedr CQ/QP/SRQ, mana WQ/QP, ionic CQ/QP. once any of those get tightened to compute and check a real minimum, they're gonna want to introduce a separate helper that passes these as distinct values. manifesting that refactor for them 🙏

🌈 RETURN 🌈

  • success → a caller-owned umem 👑 (yes, you own it, don't forget ib_umem_release(9) vibes)
  • error → ERR_PTR(...) 💀

🌸 SEE ALSO 🌸

Kernel file ./drivers/infiniband/core/umem.c plus the whole squad:

💜 that's the whole page, bestie, you ate that 💜

cute little sign-off: this one's from ./drivers/infiniband/core, dated October 2026, and it's the ib_umem_get_attr_or_va(9) page — go pin something responsibly 🧚‍♀️⭐

📦 where this page comes from