mm: retain consistent pidfd syscall naming
I think there's value in consistent api naming. So far we have
pidfd_open(), pidfd_send_signal(), pidfd_getfd(), likely there's going
to be a pidfd_addfd() in the near future. process_madvise() would
currently be the only syscall not fitting in that set. It probably
doesn't matter much whether we call it process_madvise() or
pidfd_madvise() and as long as noone has serious problems with renaming
this I'd vote to keep naming consistent. This is also way nicer for
userspace.
I tested this patch on the akpm branch:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git akpm
It can be applied directly on top of Minchan's patch:
https://lore.kernel.org/lkml/20200516012055.126205-1-minchan@kernel.org
Here's also the adapted commit message:
Based on discussion[1], people didn't feel we need to support both
pid and pidfd for every new coming API[2] so this patch keeps only
pidfd. This patch also changes flags's type with "unsigned int".
So finally, the API is as follows,
ssize_t pidfd_madvise(int pidfd, const struct iovec *iovec,
unsigned long vlen, int advice, unsigned int flags);
DESCRIPTION
The pidfd_madvise() system call is used to give advice or directions
to the kernel about the address ranges from external process as well as
local process. It provides the advice to address ranges of process
described by iovec and vlen. The goal of such advice is to improve system
or application performance.
The pidfd selects the process referred to by the PID file descriptor
specified in pidfd. (See pidofd_open(2) for further information)
The pointer iovec points to an array of iovec structures, defined in
<sys/uio.h> as:
struct iovec {
void *iov_base; /* starting address */
size_t iov_len; /* number of bytes to be advised */
};
The iovec describes address ranges beginning at address(iov_base)
and with size length of bytes(iov_len).
The vlen represents the number of elements in iovec.
The advice is indicated in the advice argument, which is one of the
following at this moment if the target process specified by idtype and
id is external.
MADV_COLD
MADV_PAGEOUT
MADV_MERGEABLE
MADV_UNMERGEABLE
Permission to provide a hint to external process is governed by a
ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).
The pidfd_madvise supports every advice madvise(2) has if target
process is in same thread group with calling process so user could
use pidfd_madvise(2) to extend existing madvise(2) to support
vector address ranges.
RETURN VALUE
On success, pidfd_madvise() returns the number of bytes advised.
This return value may be less than the total number of requested
bytes, if an error occurred. The caller should check return value
to determine whether a partial advice occurred.
[1] https://lore.kernel.org/linux-mm/20200509124817.xmrvsrq3mla6b76k@wittgenstein/
[2] https://lore.kernel.org/linux-mm/9d849087-3359-c4ab-fbec-859e8186c509@virtuozzo.com/
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
22 files changed
