mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ridong Chen <ridong.chen@linux.dev>
To: "Gregory Price (Meta)" <gourry@gourry.net>, cgroups@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	longman@redhat.com, tj@kernel.org, hannes@cmpxchg.org,
	mkoutny@suse.com, akpm@linux-foundation.org,
	feng.79.tang@gmail.com, mhocko@suse.com
Subject: Re: [PATCH] cgroup/cpuset: check effective mems for a movable-only configuration
Date: Fri, 23 Oct 2026 14:03:18 +0800	[thread overview]
Message-ID: <47c16837-728b-4127-9d41-ff4ec7f02712@linux.dev> (raw)
In-Reply-To: <20261022043943.3125239-1-gourry@gourry.net>



On 10/22/2026 12:39 PM, Gregory Price (Meta) wrote:
> check_insane_mems_config() warns and enables cpusets_insane_config_key
> when a cpuset's tasks can allocate only from movable memory.
> 
> In cgroup v2 the request may name a memoryless node, which has no zones
> and cpusets reports it as a movable-only nodemask.
> 
> For example, with node 2 a CPU-only node:
> 
>    # echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control
>    # mkdir /sys/fs/cgroup/test
>    # echo 2 > /sys/fs/cgroup/test/cpuset.mems
>    # cat /sys/fs/cgroup/test/cpuset.mems.effective
>      0-1
>    # dmesg
>      Unsupported (movable nodes only) cpuset configuration detected (nmask=2)!
> 
> This is a bit confusing, especially consider mems.effective ends up with
> a valid nodemask by-design (cpuset.mems is treated as-if it were empty).
> 
> Check each new effective mask in update_nodemasks_hier() instead, as the
> hotplug path already does. The allocator's bail-out tests the task's
> mems_allowed, which comes from the effective mask.
> 
> A request naming a movable-only not present in the parent's nodemask
> no longer warns (since, again, the cpuset.mems gets overridden and
> treated as empty). However, it will warn if the parent's mems include
> the node later.
> 
> For Example, with node 3 a movable-only node:
> 
>    # echo 0 > /sys/fs/cgroup/test/cpuset.mems
>    # echo 3 > /sys/fs/cgroup/test/child/cpuset.mems
>    # cat /sys/fs/cgroup/test/child/cpuset.mems.effective
>      0
>    # dmesg
>      { empty }
>    # echo 0,3 > /sys/fs/cgroup/test/cpuset.mems
>    # cat /sys/fs/cgroup/test/child/cpuset.mems.effective
>      3
>    # dmesg
>      Unsupported (movable nodes only) cpuset configuration detected (nmask=3)!
> 
> Fixes: 8ca1b5a49885 ("mm/page_alloc: detect allocation forbidden by cpuset and bail out early")
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---
>   kernel/cgroup/cpuset.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 8ee239d5c6b48..70fbece1b9399 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2795,6 +2795,8 @@ static void update_nodemasks_hier(struct cpuset *cs, nodemask_t *new_mems)
>   			continue;
>   		rcu_read_unlock();
>   
> +		check_insane_mems_config(new_mems);
> +
>   		spin_lock_irq(&callback_lock);
>   		cp->effective_mems = *new_mems;
>   		spin_unlock_irq(&callback_lock);
> @@ -2848,8 +2850,6 @@ static int update_nodemask(struct cpuset *cs, struct cpuset *trialcs,
>   	if (retval < 0)
>   		return retval;
>   
> -	check_insane_mems_config(&trialcs->mems_allowed);
> -
>   	spin_lock_irq(&callback_lock);
>   	cs->mems_allowed = trialcs->mems_allowed;
>   	spin_unlock_irq(&callback_lock);

LGTM.

Reviewed-by: Ridong Chen <ridong.chen@linux.dev>
Thanks.

-- 
Best regards
Ridong


      parent reply	other threads:[~2026-10-23  6:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22  4:39 Gregory Price (Meta)
2026-10-22 13:03 ` Waiman Long
2026-10-23  6:03 ` Ridong Chen [this message]

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=47c16837-728b-4127-9d41-ff4ec7f02712@linux.dev \
    --to=ridong.chen@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=feng.79.tang@gmail.com \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=tj@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®