process_madvise(2)

💅 process_madvise — give advice about use of memory to a process

okay so bestie, we're in section 2 of the system calls manual and today's lecture is process_madvise(2). it's the little sibling of madvise but it can whisper sweet memory advice to other processes too. iconic behavior honestly.

---

🎀 LIBRARY

Standard C library (libc, -lc)

---

✨ SYNOPSIS

#include <sys/mman.h>

ssize_t process_madvise(size_t n;
                        int pidfd, const struct iovec iovec[n],
                        size_t n, int advice, unsigned int flags);

---

🦋 DESCRIPTION

so the process_madvise() system call is literally just you giving advice or directions to the kernel about the address ranges of another process, or of the calling process itself. it hands over the advice for the address ranges described by iovec and n. and the whole point of giving this advice? to improve system or application performance. glow-up for your machine 💖

the pidfd argument is a PID file descriptor (peep pidfd_open(2)) that specifies which process the advice gets applied to.

the iovec pointer points to an array of iovec structures, described over in iovec(3type).

n says how many elements are in that array of iovec structures. this value must be less than or equal to IOV_MAX (defined in <limits.h> or accessible via the call sysconf(_SC_IOV_MAX)).

if we're manipulating another process, or we're on Linux before 6.13, then the advice argument is one of these values:

• MADV_COLD — see madvise(2).
• MADV_COLLAPSE — see madvise(2).
• MADV_PAGEOUT — see madvise(2).
• MADV_WILLNEED — see madvise(2).

since Linux 6.13 though, when manipulating the calling process, any advice flag is permitted. yes queen, all of them 🌈

the flags argument is reserved for future use; currently, this argument must be specified as 0. no exceptions, don't be chaotic.

the n and iovec arguments are checked before applying any advice. if n is too big, or iovec is invalid, then an error gets returned immediately and no advice will be applied. gatekeeping your bad inputs before anything happens, we love a system call with boundaries 🫶

and here's the messy part: the advice might be applied to only a part of iovec if one of its elements points to an invalid memory region in the remote process. no further elements will be processed beyond that point. (go read the discussion about partial advice down in RETURN VALUE.)

since Linux 5.12, permission to apply advice to another process is governed by the ptrace access mode PTRACE_MODE_READ_FSCREDS check (see ptrace(2)); and on top of that, because of the performance implications of applying the advice, the caller must have the CAP_SYS_NICE capability (see capabilities(7)). yeah, you need the fancy badge for this one 💅

---

🔥 RETURN VALUE

on success, process_madvise() returns the number of bytes advised. this return value may be less than the total number of requested bytes if an error occurred after some iovec elements were already processed. so bestie, check the return value to figure out whether a partial advice happened. do not skip this, i'm begging 😭

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

---

💀 ERRORS

• EBADF — pidfd is not a valid PID file descriptor.
• EFAULT — the memory described by iovec is outside the accessible address space of the process referred to by pidfd.
• EINVAL — flags is not 0.
• EINVAL — the sum of the iov_len values of iovec overflows a ssize_t value.
• EINVAL — n 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 pidfd.
• ESRCH — the target process does not exist (i.e., it has terminated and been waited on).

see madvise(2) for advice-specific errors. 💜

---

⭐ STANDARDS

Linux.

---

🌸 HISTORY

Linux 5.10, glibc 2.36.

support for this system call is optional, depending on the setting of the CONFIG_ADVISE_SYSCALLS configuration option. so like, it might just not be there. vibe check your kernel config first 🙈

when this system call first appeared in Linux 5.10, permission to apply advice to another process was entirely governed by ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check (see ptrace(2)). this requirement was relaxed in Linux 5.12 so that the caller didn't require full control over the target process. character development, honestly 👑

---

👑 SEE ALSO

madvise(2), pidfd_open(2), process_vm_readv(2), process_vm_write(2)

---

okay that's the whole page, bestie. you're now certified in cross-process memory advice giving. go forth and be gentle with other people's address spaces 🧚

this has been Linux man-pages 6.20, dated 2026-02-22 — mwah, stan the man-pages maintainers 💖