Gregory Price <gourry.memverge@xxxxxxxxx> writes: > 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 <gregory.price@xxxxxxxxxxxx> > --- > 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
