I suggest to move the flags in "mode" parameter (MPOL_F_STATIC_NODES,
MPOL_F_RELATIVE_NODES, MPOL_F_NUMA_BALANCING, etc.) to "flags"
parameter, otherwise, why add it?
And, how about add a "home_node" parameter? I don't think that it's a
good idea to add another new syscall for pidfd_set_mempolicy_home_node()
in the future.
IMHO, "The first four APIS" and "The last one" isn't easy to be
understood. How about
"sys_pidfd_set_mempolicy sets the mempolicy of task specified in the
pidfd, the others affect only the calling task, ...".
Why add "sys_"? I fount that there's no "sys_" before set_mempolicy()/mbind() etc.
+void mpol_put_async(struct task_struct *task, struct mempolicy *p)
How about change __mpol_put() directly?
Why can we fall back to freeing directly if task_work_add() failed?
Should we check the return code and fall back only if -ESRCH and WARN
for other cases?
+ }
Why do we need to write lock mmap_sem? IIUC, we don't touch vma.
Thanks again for your suggestion./*
Because we will change task_struct->mempolicy in another task, we need
to use kind of "load acquire" / "store release" memory order. For
example, rcu_dereference() / rcu_assign_pointer(), etc.