All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gregory.price@memverge.com>
To: Chunsheng Luo <luochunsheng@ustc.edu>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mempolicy: check home_node is in the nodes of policy
Date: Mon, 29 Jan 2024 10:12:16 -0500	[thread overview]
Message-ID: <ZbfAUEx0+2d76KWz@memverge.com> (raw)
In-Reply-To: <20240126132240.24518-1-luochunsheng@ustc.edu>

On Fri, Jan 26, 2024 at 08:22:40AM -0500, Chunsheng Luo wrote:
> set_mempolicy_home_node should be used after setting the memory
> policy. If the home_node isn't in the nodes of policy, we should
> return failure to avoid misunderstanding.
> 
> Signed-off-by: Chunsheng Luo <luochunsheng@ustc.edu>
> ---
>  mm/mempolicy.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Since it's not possible to add/remove a node to a mask without also
erasing the home node, this seems reasonable.

e.g. this is what happens presently
mbind(0-2)    :   mask(0,1,2),   home_node(NUMA_NO_NODE)
home_node(3)  :   mask(0,1,2),   home_node(3)
mbind(0-3)    :   mask(0,1,2,3), home_node(NUMA_NO_NODE)

However, it is possible for a cgroup migration or a change to
cpusets.mems_allowed to change a nodemask without somping the home_node.

e.g.:
mbind(2-3)    :   mask(2-3),  home_node(NUMA_NO_NODE)
home_node(3)  :   mask(2-3),  home_node(3)
cpusets(0-1)  :   mask(0-1),  home_node(3)

Should the rebind code also shift the home-node or un-set it accordingly
to keep the mask/home_node behavior consistent with the syscalls?

(see mpol_rebind_nodemask)


> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 10a590ee1c89..9282be2ae18e 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1536,6 +1536,12 @@ SYSCALL_DEFINE4(set_mempolicy_home_node, unsigned long, start, unsigned long, le
>  			err = -EOPNOTSUPP;
>  			break;
>  		}
> +
> +		if (!node_isset(home_node, old->nodes)) {
> +			err = -EINVAL;
> +			break;
> +		}
> +
>  		new = mpol_dup(old);
>  		if (IS_ERR(new)) {
>  			err = PTR_ERR(new);
> -- 
> 2.43.0
> 
> 


  parent reply	other threads:[~2024-01-29 15:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 13:22 [PATCH] mempolicy: check home_node is in the nodes of policy Chunsheng Luo
2024-01-28  8:29 ` Andrew Morton
2024-01-29  6:15   ` ustc
2024-01-29 15:12 ` Gregory Price [this message]
2024-01-30  2:29   ` Chunsheng Luo
2024-01-30  4:02     ` Chunsheng Luo

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=ZbfAUEx0+2d76KWz@memverge.com \
    --to=gregory.price@memverge.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luochunsheng@ustc.edu \
    /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.