From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A4C4312821 for ; Mon, 17 Nov 2025 20:50:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763412632; cv=none; b=LkW02jOJ0D/kgL3zstHzVOnllxI0pK+Shq56vzmCDw+mUYv4GmQ0S3B6htikSzTXpI34uCdGO1JiUlvZtmMbf3QnFlQuS4lcZfCsbw8KMZ8zZZ4Fh/ZP9XNiQPT3oyMBSGdFXAmLZQosMr91/kCsl+cWMpw0nD0DBGUig+2jZrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763412632; c=relaxed/simple; bh=iTDw2sXymZVOxmraPAFZ4IFal7IrCX/rogWy3d5ivc8=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=it23iuJ/uC/AVxAWv7GXFbIx9snvABEZqNuuRqha6LX08zfwdXV6wVYufU8jh7T9zqxAV7O4WJta2YmENN3ExdH/Ec/WyzMF0fFbZz3F7D3NN5jrFc+wJkfSnAn/NTsyKFRzMF8zSi68lOQSLaEXlUYJeG4s5DaS9UIFBo1y710= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GVfJ69Te; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=CTP67pCH; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GVfJ69Te"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="CTP67pCH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763412629; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=49uZWUi3tUOvugaZjqm25X08vrc3EIGz57ACFwR7xhs=; b=GVfJ69Te5IAXiyZn9ggW7D5VKfs5ox0PURSDOLNBmRKPE6zRmHFOeDpdGZ6ZXOHqL7bPGm 8Sa3w8kAtMjJHbFaR/bXCpyTLhuvK9cjTR8V64oPDji6d5RkLV/kX9+lTdly8qtqpArY9i OaGUpbKE1uwbucZTnSmanyycRFjws80= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-611-ohrB_UPPMAWJx00dw7Xpiw-1; Mon, 17 Nov 2025 15:50:27 -0500 X-MC-Unique: ohrB_UPPMAWJx00dw7Xpiw-1 X-Mimecast-MFC-AGG-ID: ohrB_UPPMAWJx00dw7Xpiw_1763412627 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-882381f2092so226924726d6.1 for ; Mon, 17 Nov 2025 12:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1763412627; x=1764017427; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=49uZWUi3tUOvugaZjqm25X08vrc3EIGz57ACFwR7xhs=; b=CTP67pCH2810nKUckaKalKtn5gBtN2K/4EglEUyCrX5qF7eylO6soK9FP/8s2H/lZL 0yl196rRoY+m9dAMb7SkLHIqKpYLHR1kPqQXHNaBd+sPeEbZDSzYZ76st2dO4C831VOD H1nVsrE/2BGIjL5zvHS179In6zksMJe0+482wWR0jmpmtAWOG505jFlWMb/J/VtveZdq 2NLTtC/v96gmgUSNNTMOV3ROS/UsKozFCZFFTw9PnRFHegiW0p7MNlbE1GYKkvi6MQg0 4tbTdJmTIO3cj/9K3VIsUtLKfvk38IAfhHXNKbv5leDbjSYTgY1EY+dZHegORFxLDya9 gyMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763412627; x=1764017427; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=49uZWUi3tUOvugaZjqm25X08vrc3EIGz57ACFwR7xhs=; b=no5L6qLseicdC1khUX5ClpJq6kti1Mu/tvp52m4TFDmkuLS8gkyGOO8oNsyIU/ee/b fFmTIJn4+StK3TK/6hchObYn59BDX5ulp/akb2iRkM8dOS/sKZ8uZVIJJpmZZgf8kfiP LYGLsjB/1PdOeBMPoUf+CQeaaoMaVl0XeKbsXFmJsM2tGZ/4HqFudgtAHSEsrk/nge8e jTrdY7Hpgxv1Pg7mbMZg1tnBAA2XbcnoBSEIY50jUScZg/y3Ud+GnqbL5cDOrLCsyuEQ J3zyC+H7doElUhifImLzHKrOEBUMogr7Kv5UgTyei/i0knqsFRimTXFT/KGfg5upgp3K VauQ== X-Forwarded-Encrypted: i=1; AJvYcCVrIwnp6bzabEXe/mEYw0FgBHUskGQ+DYppWVHcaWzTdTjqWvb0CtUluIX8GcgY9d3D3o2abXXMt0V349M=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4zanAwuuJFL4cT7GOdUHQKZ/dle1B875cRhH6Q4iixpqyXJaK Iokse+Ptozr4itt7PAj1N4fH9HMUSpgPP8jk5M5g4o1++7ODLu7FiW4kAWoyP0ESzrJHqUz69hf bKw/i7dxYevzoqWxhD7ud9VchUX2KfmLhY2Drl0l/zZJPtYnwTIM2h/lSrBQLz9keEVjaPgEWrw == X-Gm-Gg: ASbGncvRo8FjKUpEvL+NNpFJjQ+/QsTeRgsFVuIP9MboDNcMa4Q97fQDGCgFC+gXzKe WOAk/j6ODiy7OImap4g6wCXaUWOa/PN4JexA7COH+uwk8d0bP8QcsWDFetepJslgeVpxVjkjhkx wQ0fKd/vgEb6SFUgxHZe6VUdkWLy0julrbs/AdntjuqG0RO+HnEGsuTuxh2UxfgtdNtjZtHUH/v za+bUjUPxvCLq++8wPpyOp8jmCqeieIo0eNFb6/QIXw2cVDBPJaIOJvhEsDga5r+gsnwd94rt74 /2ArgzxsrQZK0HC2/pueNWRZ0C1VLgcRJtJA8/F37VCPi8YPS3BMVi8adyMcsqQreNUshB62XRb +b32EKFSnWVV4OJ3o2r5oqFEJg3GyXOdRkTvsgeP2PO50eA== X-Received: by 2002:ad4:4ea5:0:b0:882:4632:cf7e with SMTP id 6a1803df08f44-882925bdb7amr193219446d6.12.1763412626850; Mon, 17 Nov 2025 12:50:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IEvtmUHJOgdOp9Ll8LYfjQHw13mjo1gfl8WaqWutebE1EEcEghA6cIfuHVo8ijvaG0eeD5fpQ== X-Received: by 2002:ad4:4ea5:0:b0:882:4632:cf7e with SMTP id 6a1803df08f44-882925bdb7amr193219186d6.12.1763412626436; Mon, 17 Nov 2025 12:50:26 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88286577cbesm100345946d6.46.2025.11.17.12.50.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Nov 2025 12:50:25 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <145d57ba-ed38-40b6-a495-57691cb41b63@redhat.com> Date: Mon, 17 Nov 2025 15:50:24 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next v3] cpuset: Treat cpusets in attaching as populated To: Chen Ridong , tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, lujialin4@huawei.com, chenridong@huawei.com References: <20251114020847.1040546-1-chenridong@huaweicloud.com> Content-Language: en-US In-Reply-To: <20251114020847.1040546-1-chenridong@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/13/25 9:08 PM, Chen Ridong wrote: > From: Chen Ridong > > Currently, the check for whether a partition is populated does not > account for tasks in the cpuset of attaching. This is a corner case > that can leave a task stuck in a partition with no effective CPUs. > > The race condition occurs as follows: > > cpu0 cpu1 > //cpuset A with cpu N > migrate task p to A > cpuset_can_attach > // with effective cpus > // check ok > > // cpuset_mutex is not held // clear cpuset.cpus.exclusive > // making effective cpus empty > update_exclusive_cpumask > // tasks_nocpu_error check ok > // empty effective cpus, partition valid > cpuset_attach > ... > // task p stays in A, with non-effective cpus. > > To fix this issue, this patch introduces cs_is_populated, which considers > tasks in the attaching cpuset. This new helper is used in validate_change > and partition_is_populated. > > Fixes: e2d59900d936 ("cgroup/cpuset: Allow no-task partition to have empty cpuset.cpus.effective") > Signed-off-by: Chen Ridong > --- > kernel/cgroup/cpuset.c | 35 +++++++++++++++++++++++++++-------- > 1 file changed, 27 insertions(+), 8 deletions(-) > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > index daf813386260..8bf7c38ba320 100644 > --- a/kernel/cgroup/cpuset.c > +++ b/kernel/cgroup/cpuset.c > @@ -356,6 +356,15 @@ static inline bool is_in_v2_mode(void) > (cpuset_cgrp_subsys.root->flags & CGRP_ROOT_CPUSET_V2_MODE); > } > > +static inline bool cpuset_is_populated(struct cpuset *cs) > +{ > + lockdep_assert_held(&cpuset_mutex); > + > + /* Cpusets in the process of attaching should be considered as populated */ > + return cgroup_is_populated(cs->css.cgroup) || > + cs->attach_in_progress; > +} > + > /** > * partition_is_populated - check if partition has tasks > * @cs: partition root to be checked > @@ -373,19 +382,29 @@ static inline bool is_in_v2_mode(void) > static inline bool partition_is_populated(struct cpuset *cs, > struct cpuset *excluded_child) > { > - struct cgroup_subsys_state *css; > - struct cpuset *child; > + struct cpuset *cp; > + struct cgroup_subsys_state *pos_css; > > - if (cs->css.cgroup->nr_populated_csets) > + /* > + * We cannot call cs_is_populated(cs) directly, as > + * nr_populated_domain_children may include populated > + * csets from descendants that are partitions. > + */ > + if (cs->css.cgroup->nr_populated_csets || > + cs->attach_in_progress) > return true; > > rcu_read_lock(); > - cpuset_for_each_child(child, css, cs) { > - if (child == excluded_child) > + cpuset_for_each_descendant_pre(cp, pos_css, cs) { > + if (cp == cs || cp == excluded_child) > continue; > - if (is_partition_valid(child)) > + > + if (is_partition_valid(cp)) { > + pos_css = css_rightmost_descendant(pos_css); > continue; > - if (cgroup_is_populated(child->css.cgroup)) { > + } > + > + if (cpuset_is_populated(cp)) { > rcu_read_unlock(); > return true; > } > @@ -670,7 +689,7 @@ static int validate_change(struct cpuset *cur, struct cpuset *trial) > * be changed to have empty cpus_allowed or mems_allowed. > */ > ret = -ENOSPC; > - if ((cgroup_is_populated(cur->css.cgroup) || cur->attach_in_progress)) { > + if (cpuset_is_populated(cur)) { > if (!cpumask_empty(cur->cpus_allowed) && > cpumask_empty(trial->cpus_allowed)) > goto out; Reviewed-by: Waiman Long