All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gregory.price@memverge.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Gregory Price <gourry.memverge@gmail.com>,
	linux-mm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, linux-api@vger.kernel.org,
	linux-cxl@vger.kernel.org, luto@kernel.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	hpa@zytor.com, arnd@arndb.de, akpm@linux-foundation.org,
	x86@kernel.org
Subject: Re: [RFC PATCH 3/3] mm/migrate: Create move_phys_pages syscall
Date: Sun, 10 Sep 2023 07:49:53 -0400	[thread overview]
Message-ID: <ZP2tYY00/q9ElFQn@memverge.com> (raw)
In-Reply-To: <878r9dzrxj.fsf@meer.lwn.net>

On Sun, Sep 10, 2023 at 02:36:40PM -0600, Jonathan Corbet wrote:
> Gregory Price <gourry.memverge@gmail.com> 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@memverge.com>
> > ---
> >  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

  reply	other threads:[~2023-09-11 21:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07  7:54 [RFC 0/3] sys_move_phy_pages system call Gregory Price
2023-09-07  7:54 ` [RFC PATCH 1/3] mm/migrate: remove unused mm argument from do_move_pages_to_node Gregory Price
2023-09-07  7:54 ` [RFC PATCH 2/3] mm/migrate: refactor add_page_for_migration for code re-use Gregory Price
2023-09-07  7:54 ` [RFC PATCH 3/3] mm/migrate: Create move_phys_pages syscall Gregory Price
2023-09-08 21:59   ` kernel test robot
2023-09-08 22:33   ` kernel test robot
2023-09-08 22:43   ` kernel test robot
2023-09-09  8:03   ` Arnd Bergmann
2023-09-08  7:46     ` Gregory Price
2023-09-09 15:18       ` Arnd Bergmann
2023-09-10 12:52         ` Gregory Price
2023-09-11 17:26           ` Arnd Bergmann
2023-09-10 15:01             ` Gregory Price
2023-09-10 20:36   ` Jonathan Corbet
2023-09-10 11:49     ` Gregory Price [this message]
2023-09-19  3:34       ` Andy Lutomirski
2023-09-19 16:31         ` Gregory Price
2023-09-19 17:59           ` Andy Lutomirski
2023-09-19 18:20             ` Gregory Price
2023-09-19 18:52               ` Andy Lutomirski
2023-09-19 19:59                 ` Gregory Price
2023-09-19  0:17   ` Thomas Gleixner
2023-09-19 15:57     ` Gregory Price
2023-09-19 16:37     ` Gregory Price

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZP2tYY00/q9ElFQn@memverge.com \
    --to=gregory.price@memverge.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=gourry.memverge@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.