mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: "Gregory Price (Meta)" <gourry@gourry.net>, cgroups@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	ridong.chen@linux.dev, 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: Thu, 22 Oct 2026 09:03:49 -0400	[thread overview]
Message-ID: <b1c7acc8-1a6d-4395-9b5f-cd5635f05d7b@redhat.com> (raw)
In-Reply-To: <20261022043943.3125239-1-gourry@gourry.net>

On 10/22/26 12:39 AM, 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);
Reviewed-by: Waiman Long <longman@redhat.com>


      reply	other threads:[~2026-10-22 13:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22  4:39 Gregory Price (Meta)
2026-10-22 13:03 ` Waiman Long [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=b1c7acc8-1a6d-4395-9b5f-cd5635f05d7b@redhat.com \
    --to=longman@redhat.com \
    --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=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=ridong.chen@linux.dev \
    --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®