blk_rq_map_user_iov(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’« blk_rq_map_user_iov β€” the kernel API manual, but make it make sense

okay so bestie, welcome to the <purple>Kernel API Manual<//purple> entry for blk_rq_map_user_iov(9) β€” the function that maps your user data onto a request so passthrough requests can go brrr. it's giving "glue code but make it iconic" πŸ’…


✨ SYNOPSIS ✨

int blk_rq_map_user_iov (struct request_queue *q , struct request *rq ,
struct rq_map_data *map_data , const struct iov_iter *iter , gfp_t gfp_mask );

six arguments, one int coming back at you. yes that's a lot of pointers. no you're not allowed to skip any of them. 🫢


πŸŽ€ ARGUMENTS πŸŽ€

  • q β€” the request queue where the request should be inserted. like, where does this request live? right here, bestie. 🏠
  • rq β€” the request you're mapping data to. the main character, honestly. πŸ‘‘
  • map_data β€” pointer to the rq_map_data holding the pages (if necessary). note the "if necessary" β€” it's conditional, iykyk.
  • iter β€” the iovec iterator. this is the actual user data you're feeding in. πŸ“
  • gfp_mask β€” memory allocation flags. the boring-but-load-bearing one. ngl you need these.

🌸 DESCRIPTION 🌸

okay so here's the vibe: data gets mapped directly for zero copy I/O if possible. zero copy!! we love efficiency!! πŸ”₯

but if that's not possible? a kernel bounce buffer is used instead. not the glow-up we wanted, but it's the fallback and it works. πŸ’€

🚨 real talk: you must issue a matching blk_rq_unmap_user at the end of the I/O, and you gotta do it while still in process context. don't just leave it mapped and walk away, that's not the move, periodt. πŸ™ˆ

πŸ¦‹ SEE ALSO πŸ¦‹


πŸ’– cute little sign-off πŸ’–

this page lives down in ./block, dated October 2026, brought to you by the <rainbow>Kernel API Manual<//rainbow>. go map those iovecs, bestie β€” and remember the unmap. mwah πŸ’‹βœ¨

πŸ“¦ where this page comes from