linux-kernel - Re: [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally modifiable via syscall and procfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 27 Nov 2023 11:14:44 -0500
From:   Gregory Price <gregory.price@...verge.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Gregory Price <gourry.memverge@...il.com>, linux-mm@...ck.org,
        linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, arnd@...db.de, tglx@...utronix.de,
        luto@...nel.org, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        tj@...nel.org, ying.huang@...el.com
Subject: Re: [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally
 modifiable via syscall and procfs

On Mon, Nov 27, 2023 at 04:29:56PM +0100, Michal Hocko wrote:
> Sorry, didn't have much time to do a proper review. Couple of points
> here at least.
> 
> > 
> > So... yeah... the is one area I think the community very much needs to
> > comment:  set/get_mempolicy2, many new mempolicy syscalls, procfs? All
> > of the above?
> 
> I think we should actively avoid using proc interface. The most
> reasonable way would be to add get_mempolicy2 interface that would allow
> extensions and then create a pidfd counterpart to allow acting on a
> remote task. The latter would require some changes to make mempolicy
> code less current oriented.

Sounds good, I'll pull my get/set_mempolicy2 RFC on top of this.

Just context: patches 1-6 refactor mempolicy to allow remote task
twiddling (fixing the current-oriented issues), and patch 7 adds the pidfd
interfaces you describe above.

Couple Questions

1) Should we consider simply adding a pidfd arg to set/get_mempolicy2,
   where if (pidfd == 0), then it operates on current, otherwise it
   operates on the target task?  That would mitigate the need for what
   amounts to the exact same interface.

2) Should we combine all the existing operations into set_mempolicy2 and
   add an operation arg.

   set_mempolicy2(pidfd, arg_struct, len)

   struct {
     int pidfd; /* optional */
     int operation; /* describe which op_args to use */
     union {
       struct {
       } set_mempolicy;
       struct {
       } set_vma_home_node;
       struct {
       } mbind;
       ...
     } op_args;
   } args;

   capturing:
     sys_set_mempolicy
     sys_set_mempolicy_home_node
     sys_mbind

   or should we just make a separate interface for mbind/home_node to
   limit complexity of the single syscall?

Personally I like the dispatch for the extensibility nature of the arg
struct, but I can understand wanting to limit complexity of a syscall
interface for a variety of reasons.

~Gregory