_copy_mc_to_iter(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… _copy_mc_to_iter(9) β€” like, the Kernel API Manual one

okay bestie, buckle up, we're reading a man page from the Kernel API Manual section 9, and honestly? this one is kind of a baddie. it's giving "low-level memory safety with main character energy" and i'm obsessed. πŸ¦‹


✨ NAME ✨

_copy_mc_to_iter β€” copy to iter, but make it safe, because it handles source memory error exceptions πŸ’€ (yes, machine checks, we'll get there, don't panic)


🌸 SYNOPSIS 🌸

size_t _copy_mc_to_iter (const void *addr , size_t bytes , struct
       iov_iter *i );

that's it. three args. she's sleek. πŸŽ€


🫢 ARGUMENTS 🫢

  • addr β€” the source kernel address, like, where the data lives right now 🏠
  • bytes β€” total transfer length, aka how much we're moving, fr fr
  • i β€” the destination iterator, the glow-up destination, the final form ✨

πŸ”₯ DESCRIPTION πŸ”₯

so here's the tea β˜• β€” the pmem driver deploys this function for the dax operation (dax_copy_to_iter) for dax reads (which bypass the page-cache and the block-layer, no cap, they just go straight there πŸ’¨).

and then? upon #MC (machine check, the scary one 😭), read(2) aborts and returns EIO, or returns the bytes successfully copied. so worst case she still tells you what she managed to do. iconic behavior honestly πŸ‘‘

now, the main differences between this and your typical _copy_to_iter β€” let me list them because there are two and both matter:

  • typical tail/residue handling after a fault retries the copy byte-by-byte until the fault happens again 😬 but re-triggering machine checks is potentially fatal, so this implementation instead uses source alignment and poison alignment assumptions to avoid re-triggering hardware exceptions. like, she does NOT want to poke the bear again, and honestly? valid. πŸ™ˆ
  • ITER_KVEC and ITER_BVEC can return short copies. compare that to copy_to_iter, where only ITER_IOVEC attempts might return a short copy. so yeah, she's built different πŸ’…
⚠️ real talk: the byte-by-byte retry thing isn't just slow, re-triggering machine checks is potentially fatal β€” that's why the alignment assumptions exist. do not mess with that logic, bestie. 🚨

🌈 RETURN 🌈

number of bytes copied (may be 0) β€” yes, zero is a possible answer, and no, that's not a vibe fail, that's just the contract πŸ“


⭐ SEE ALSO ⭐

all my faves from the kernel file ./lib/iov_iter.c, go give them a read, iykyk πŸ’–


and that's the whole page, bestie πŸŽ€ sourced straight from ./lib, dated October 2026, and no i did not make any of that up. mwah πŸ’‹ slay ✨

πŸ“¦ where this page comes from