process_vm_readv(2)

✨ process_vm_readv, process_vm_writev — a lil vibe transfer between process address spaces ✨

okay bestie, so this is a page from the Linux man-pages, section 2 (System Calls Manual) 🫶 and it's about two syscalls that literally let you yeet data straight between two processes' address spaces. no cap.

---

🌸 NAME 🌸

process_vm_readv, process_vm_writev — transfer data between process address spaces

🎀 LIBRARY 🎀

Standard C library (libc, -lc)

🧚 SYNOPSIS 🧚

#include <sys/uio.h>

ssize_t process_vm_readv(pid_t pid,
                       const struct iovec *local_iov,
                       unsigned long liovcnt,
                       const struct iovec *remote_iov,
                       unsigned long riovcnt,
                       unsigned long flags);
ssize_t process_vm_writev(pid_t pid,
                       const struct iovec *local_iov,
                       unsigned long liovcnt,
                       const struct iovec *remote_iov,
                       unsigned long riovcnt,
                       unsigned long flags);

⭐ Feature Test Macro Requirements for glibc (see feature_test_macros(7)): ⭐

process_vm_readv(), process_vm_writev():
    _GNU_SOURCE

💜 DESCRIPTION 💜

so these syscalls move data between the address space of the process that's calling them (we call that one "the local process" 💁♀️) and the process identified by pid (that's "the remote process"). the data just goes directly between the two address spaces, it does not pass through kernel space. it's giving skipping-the-middleman energy. iconic.

process_vm_readv() transfers data from the remote process to the local process. the stuff that's getting transferred is described by remote_iov and riovcnt: remote_iov is a pointer to an array describing address ranges in the process pid, and riovcnt says how many elements are in remote_iov. the data lands in the locations described by local_iov and liovcnt: local_iov is a pointer to an array describing address ranges in the calling process, and liovcnt says how many elements are in local_iov. 🎀

process_vm_writev() is literally the converse of process_vm_readv()—it transfers data from the local process to the remote process. other than which direction the data's going, the arguments liovcnt, local_iov, riovcnt, and remote_iov mean exactly the same thing as they do for process_vm_readv(). 💅

the local_iov and remote_iov args point to an array of iovec structures — those are described in iovec(3type). 🦋

buffers get processed in array order, bestie. that means process_vm_readv() completely fills local_iov[0] before it moves on to local_iov[1], and so on. same energy with remote_iov[0] — it's completely read before it proceeds to remote_iov[1], and so on. ✨

similarly, process_vm_writev() writes out the entire contents of local_iov[0] before proceeding to local_iov[1], and it completely fills remote_iov[0] before proceeding to remote_iov[1]. no cutting in line, periodt. 😌

and get this — the lengths of remote_iov[i].iov_len and local_iov[i].iov_len do not have to be the same. so you can split a single local buffer into multiple remote buffers, or the other way around. slay, flexible queen. 👑

the flags argument is currently unused and must be set to 0.

the values you put in liovcnt and riovcnt must be less than or equal to IOV_MAX (it's defined in <limits.h> or you can grab it via the call sysconf(_SC_IOV_MAX)).

the count arguments and local_iov get checked before any transfers happen. so if the counts are too big, or local_iov is invalid, or the addresses point at regions that are inaccessible to the local process — none of the vectors get processed and an error comes back immediately. 💀

okay but heads up 🔥 — these syscalls do NOT check the memory regions in the remote process until right before doing the read/write. so a partial read/write (peep RETURN VALUE) can happen if one of the remote_iov elements points to an invalid memory region in the remote process. and no further reads/writes get attempted beyond that point. keep that in mind when you're trying to read data of unknown length (like C strings that are null-terminated) from a remote process — avoid spanning memory pages (typically 4 KiB) in a single remote iovec element. instead, split the remote read into two remote_iov elements and have them merge back into a single write local_iov entry. the first read entry goes up to the page boundary, while the second starts on the next page boundary. iykyk 💅

permission to read from or write to another process is governed by a ptrace access mode PTRACE_MODE_ATTACH_REALCREDS check; see ptrace(2). 🔐

💖 RETURN VALUE 💖

on success, process_vm_readv() returns the number of bytes read and process_vm_writev() returns the number of bytes written. 👏 this return value may be less than the total number of requested bytes, if a partial read/write occurred. (partial transfers apply at the granularity of pages in the remote process. if a remote iovec element spans multiple pages, and one of those pages is invalid or not resident, data may be transferred from/to the pages preceding the failing page, which results in a partial transfer that splits a single iovec element. 😭) the caller should check the return value to figure out whether a partial read/write happened.

on error, -1 is returned and errno is set to indicate the error. 💀

🙈 ERRORS 🙈

• EFAULT — the memory described by local_iov is outside the caller's accessible address space.
• EFAULT — the memory described by remote_iov is outside the accessible address space of the process pid.
• EINVAL — the sum of the iov_len values of either local_iov or remote_iov overflows a ssize_t value.
• EINVAL — flags is not 0.
• EINVAL — liovcnt or riovcnt is too large.
• ENOMEM — could not allocate memory for internal copies of the iovec structures.
• EPERM — the caller does not have permission to access the address space of the process pid.
• ESRCH — no process with ID pid exists.

🌈 STANDARDS 🌈

Linux. 🐧

🍓 HISTORY 🍓

Linux 3.2, glibc 2.15.

⭐ NOTES ⭐

the data transfers performed by process_vm_readv() and process_vm_writev() are not guaranteed to be atomic in any way. no promises, bestie. 🙈

these syscalls were designed to permit fast message passing by letting messages get exchanged with a single copy operation — rather than the double copy you'd need when using, like, shared memory or pipes. efficiency queen behavior fr fr. 💅

🦋 EXAMPLES 🦋

the following code sample demonstrates the use of process_vm_readv(). it reads 20 bytes at the address 0x10000 from the process with PID 10 and writes the first 10 bytes into buf1 and the second 10 bytes into buf2. 🌸

#define _GNU_SOURCE
#include <stdlib.h>
#include <sys/types.h>
#include <sys/uio.h>

int
main(void)
{
    char          buf1[10];
    char          buf2[10];
    pid_t         pid = 10;    /* PID of remote process */
    ssize_t       nread;
    struct iovec  local[2];
    struct iovec  remote[1];

    local[0].iov_base = buf1;
    local[0].iov_len = 10;
    local[1].iov_base = buf2;
    local[1].iov_len = 10;
    remote[0].iov_base = (void *) 0x10000;
    remote[0].iov_len = 20;

    nread = process_vm_readv(pid, local, 2, remote, 1, 0);
    if (nread != 20)
        exit(EXIT_FAILURE);

    exit(EXIT_SUCCESS);
}

👑 SEE ALSO 👑

readv(2), writev(2)

---

and that's the whole page bestie, mwah 💋 this was Linux man-pages 6.20, dated 2026-05-14 — go read some more man pages, you're doing amazing, ilysm 🫶✨🎀