kmsan_memmove(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… kmsan_memmove(9) β€” the Kernel API Manual moment

okay so bestie, welcome to kmsan_memmove(9), straight out of the Kernel API Manual (that's the manual name, iykyk 🫢). Lowkey this one's a little helper with main character energy β€” it just tells KMSAN "hey, a copy happened over here" so the shadow metadata doesn't get left on read. ✨


✨ NAME ✨

kmsan_memmove β€” Notify KMSAN about a data copy within kernel.

🌸 SYNOPSIS 🌸

void kmsan_memmove (void *to , const void *from , size_t to_copy );

πŸŽ€ ARGUMENTS πŸŽ€

  • to β€” destination address in the kernel. that's where the data's going, bestie πŸ’–
  • from β€” source address in the kernel. that's where it's coming from πŸ¦‹
  • to_copy β€” -- undescribed -- 😭 fr fr the docs literally did not describe this one. not me exposing the manpage like this. it's giving "we left this as an exercise for the reader". πŸ™ˆ

πŸ’… DESCRIPTION πŸ’…

So here's the vibe: you call this after you've already hit the non-instrumented version of memmove/memcpy β€” you know, the kind implemented using assembly code πŸ”₯ β€” and the whole point is to copy KMSAN's metadata alongside. no cap, that's it. that's the function. it keeps the shadow bookkeeping in sync when the fast hand-written copy path skips the usual instrumentation. iconic, honestly. ⭐

ngl, the "invoked after" part matters β€” it's a follow-up call, not the copy itself. read the order and slay. πŸ‘‘

🌈 SEE ALSO 🌈

all the other KMSAN besties are waiting for you in that header file, go say hi πŸ’œπŸ«Ά


mwah, that's the whole page πŸ’‹ β€” brought to you by ./include/linux, dated October 2026, from the Kernel API Manual. the way this manpage ate and left zero crumbs. periodt. πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from