On Sun, Sep 10, 2023 at 02:36:40PM -0600, Jonathan Corbet wrote:

Gregory Price [off-list ref] writes:

quoted

Similar to the move_pages system call, instead of taking a pid and
list of virtual addresses, this system call takes a list of physical
addresses.

Because there is no task to validate the memory policy against, each
page needs to be interrogated to determine whether the migration is
valid, and all tasks that map it need to be interrogated.

This is accomplished via an rmap_walk on the folio containing
the page, and interrogating all tasks that map the page.

Each page must be interrogated individually, which should be
considered when using this to migrate shared regions.

The remaining logic is the same as the move_pages syscall. One
change to do_pages_move is made (to check whether an mm_struct is
passed) in order to re-use the existing migration code.

Signed-off-by: Gregory Price <redacted>
---
 arch/x86/entry/syscalls/syscall_32.tbl  |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl  |   1 +
 include/linux/syscalls.h                |   5 +
 include/uapi/asm-generic/unistd.h       |   8 +-
 kernel/sys_ni.c                         |   1 +
 mm/migrate.c                            | 178 +++++++++++++++++++++++-
 tools/include/uapi/asm-generic/unistd.h |   8 +-
 7 files changed, 197 insertions(+), 5 deletions(-)

So this is probably a silly question, but just to be sure ... what is
the permission model for this system call?  As far as I can tell, the
ability to move pages is entirely unrestricted, with the exception of
pages that would need MPOL_MF_MOVE_ALL.  If so, that seems undesirable,
but probably I'm just missing something ... ?

Thanks,

jon

Not silly, looks like when U dropped the CAP_SYS_NICE check (no task to
check against), check i neglected to add a CAP_SYS_ADMIN check.

Oversight on my part, I'll work it in with other feedback.

Thanks!
~Gregory