svc_rdma_release_ctxt(9)

📦 version 7.3.1, in nixpkgs unstable

💅 svc_rdma_release_ctxt — okay so this is from the Kernel API Manual bestie, section 9 🎀

✨ NAME ✨

svc_rdma_release_ctxt — releases the transport-specific per-rqst resources, no cap 💖

🦋 SYNOPSIS 🦋

void svc_rdma_release_ctxt (struct svc_xprt *xprt , void *vctxt );

Like, that's the whole signature. It returns void. It gives nothing back. It's giving humble. 🌸

🎀 ARGUMENTS 🎀

  • xprt — the transport that owned the context, aka the one holding the receipts 🫶
  • vctxt — the context, and where does it come from? rqstp->rq_xprt_ctxt or dr->xprt_ctxt. Both. Either. You know the vibe. ✨

🔥 DESCRIPTION 🔥

So the whole point, bestie: make sure that the recv_ctxt is released whether or not a Reply was ever sent. Like, sometimes the Reply just... doesn't happen 😭. Maybe the client closed the connection (rude), or maybe svc_process straight up dropped an RPC before the Reply got sent. Either way, this function has your back — no leaked context, periodt. 💅

It also drains any send_ctxts queued for deferred release. Why do we care? Because that way the DMA unmap and the page release run in nfsd thread context, between RPCs, instead of on the Send completion path. Which is lowkey the whole flex. 🔥 Like, keep that work off the completion path, please and thank you 👑

👑 SEE ALSO 👑

Kernel file ./net/sunrpc/xprtrdma/svc_rdma_recvfrom.c — go read it, iykyk 🧚

and that's the post 🫶💖✨

Lil sign-off from me to you: this beauty lives in ./net/sunrpc/xprtrdma, dated October 2026 — mwah, eat it up, iconic, bye bestie 💜🍓

📦 where this page comes from