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 2DB5618C2C for ; Mon, 5 Jan 2026 03:50:11 +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=1767585012; cv=none; b=ddJ3ufgfnOwCOR4Ii5d1g0UuMHc1qKAY8sxqvg0sQCzytRm+lowLUkSF1Jd7mDQN/1A40QUtMb9fX1w3FVoL9rgspGlRUfvxXi/G17/C2IkJxk9cwRJC3Ktz2LApsaE9MW5aNwJyXW4lyUqRI4vOhSwkffujy+RKA9d1od63uYw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767585012; c=relaxed/simple; bh=nWDhnM5smOejtNjvCY8DuFynO6oN7w520hhjFNQ9W6s=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=WXmaJ70lWr6iNTxlWH78W+yh1thXCk32nUph9SVymCbmbPMX6qNw3xga+vUuiOBDOQQHyw30CgHwYc1pMkEnuDeUh10yzPGMFifhlXhZRalxQsyjUy/cFVdUttXDs6qMVu35BJDGw7XQ1ppOvOMlMA9/2Nu391ss7hMfK0n2lEU= 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=ERHQUKba; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=r7tg849V; 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="ERHQUKba"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="r7tg849V" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767585010; 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=PD0MEl6rVwz2bUrpGYdOAu4vaIcu3nhZz3+NE6MOYH8=; b=ERHQUKbaL/jmJqvJd1Uy2ceQkAQU4i/KwpfbLhiV/CZF7FuplbrNaBZihJixfRsKskaad9 1jvZ8kW01IEToPLoyimN6i86kZ/FH3Z29Ou63ld/V10APcoG/5v3/fECbwgZmmhDGknOzy tTz8ZluW1PSGUxnM9QQDI0XSmPiqxf8= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-295-5Xi727JcMY2_otVp5S0vMg-1; Sun, 04 Jan 2026 22:50:09 -0500 X-MC-Unique: 5Xi727JcMY2_otVp5S0vMg-1 X-Mimecast-MFC-AGG-ID: 5Xi727JcMY2_otVp5S0vMg_1767585009 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-4ee16731ceaso277361741cf.2 for ; Sun, 04 Jan 2026 19:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1767585009; x=1768189809; 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=PD0MEl6rVwz2bUrpGYdOAu4vaIcu3nhZz3+NE6MOYH8=; b=r7tg849VtxiEz1alUCg8580Mw7c9KcF9LKwB3jRXqrYaTtJVSbeawh+q009wzS8a5b r8Fw0e84ke0HPPb+5yefau1R9HHxqNsN2TW2u6uspuTUYuJT8B5RDbfilQy5UUOL1xug TVSnvO8r5044GgQybCumZXFoAdWIvi1iivPWjMO1i6MnAGGBc0//ijgicjzK4nWAX5m3 IcHfe5AmUJfs3YTKro2kgsR7HnWiAbtKl+zPb5va49qmpkG9KAQzOdqdjHQzwM8rN6fR Ay6naNcrv6/1wqq0APpbNezJtj2M/ggUVjynh9MGhlICvu4CovVxFx3F0IWiQ+7aMpDh 77pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767585009; x=1768189809; 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=PD0MEl6rVwz2bUrpGYdOAu4vaIcu3nhZz3+NE6MOYH8=; b=Nd2oM6wxVUU/QDSjlpmYLtWuxNjqpmCQXveLRGVSz3bvSBSZ4Fypx+Sw+eNz2sIB8g kWOpOUhl8Y8DtK9H+u+hMyyV05fWdhShIat7pR5HX6lGaUmtDDBQrSDr8C+2Ca8dBi+R VPuaD5rZnml+ud5+zOV2QqpAFbo/kkqpiqxUG3eKn1Tosi8v926XgJsUfHD9CNaNFA0r gcv8N6gXnGuWwdzEjhMswumvo5+/3D4FM58L6u5o9iQsu9d9ti1fubUVI98DqTfLSgt2 D8i5x0EMcC4/o7L7J0wcUgvIAXss/gC8ZvStIHRgFDSoAgd7p+lvl0T2gkr/S4MMe38R ybqQ== X-Gm-Message-State: AOJu0Yx6BL8fl5rZAkC0HZyXew29dilPQNa1F9EMXdSfFm3Wrcq6jtt+ i6DB7xKYi/qL19muwz3wSPYnIRGbnh75lwYUiWvEcTDyRH/koxAc72Bg01QaxMtuPHEgHgXU44N yksmJbNajG7Ec2Us1KS1v5LcsXcS++Mz2lPE/qOkYMcFjCoigeJkbcORzRo/6Urv34g== X-Gm-Gg: AY/fxX4wDVz5GMW3XD1wqBDnngUvMZ+cE3XHJKx03NORYqModhuSJv04irHQF9VX1gM q9cPZJmJG4d9XHKAVc5K484zolareKKUakJfBkSVVJJ52akKGkqANLEEqysOU2caHrLSXUoSO4S bmSCJ/OsKRfRPkOGLQDd7pUhE0T7UfT6AIpiZ0OiRN7BGyH+E9dll6ZBMmMqZk0vMCRGtpk3fUy 90HR1k6y3zmwW+TdvZ0Nuih1MikIJbRudjgS3Pfqghdx5vRr4lzJzPvQP7lN1exCy+Ra/nwusLy fsy8xVEDATcRhkHbpZ5WYPUh9wj14X7ZOkUjhqmXPZAFAISmy3KrZDQ4nn2x+yB3VoGfUzHAcZY U1t7Zf3pRO11GfgGEXc/OAPmmXyN1mGBzimEI1/qwEXnCsBE7Ja/HUvAL X-Received: by 2002:ac8:5714:0:b0:4ed:b06b:d67d with SMTP id d75a77b69052e-4f4abd79a65mr582521861cf.45.1767585008733; Sun, 04 Jan 2026 19:50:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IEkwS8SyehM2DllDrPuVXzQrdiIA0f2H+sYM9WpUbWfA0eRV5XDIe78w7mLls06KQ90bmXcCQ== X-Received: by 2002:ac8:5714:0:b0:4ed:b06b:d67d with SMTP id d75a77b69052e-4f4abd79a65mr582521611cf.45.1767585008261; Sun, 04 Jan 2026 19:50:08 -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 af79cd13be357-8c0973f28b1sm3638887485a.42.2026.01.04.19.50.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 04 Jan 2026 19:50:07 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: Date: Sun, 4 Jan 2026 22:50:06 -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: [cgroup/for-6.20 PATCH v2 2/4] cgroup/cpuset: Consistently compute effective_xcpus in update_cpumasks_hier() To: Chen Ridong , Waiman Long , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Jonathan Corbet , Shuah Khan Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, Sun Shaojie References: <20260101191558.434446-1-longman@redhat.com> <20260101191558.434446-3-longman@redhat.com> <758f42df-52c2-4660-8ef7-1cbacb9323d2@huaweicloud.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/4/26 8:15 PM, Chen Ridong wrote: > > On 2026/1/5 5:25, Waiman Long wrote: >> On 1/3/26 9:48 PM, Chen Ridong wrote: >>> On 2026/1/2 3:15, Waiman Long wrote: >>>> Since commit f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() >>>> & make update_cpumasks_hier() handle remote partition"), the >>>> compute_effective_exclusive_cpumask() helper was extended to >>>> strip exclusive CPUs from siblings when computing effective_xcpus >>>> (cpuset.cpus.exclusive.effective). This helper was later renamed to >>>> compute_excpus() in commit 86bbbd1f33ab ("cpuset: Refactor exclusive >>>> CPU mask computation logic"). >>>> >>>> This helper is supposed to be used consistently to compute >>>> effective_xcpus. However, there is an exception within the callback >>>> critical section in update_cpumasks_hier() when exclusive_cpus of a >>>> valid partition root is empty. This can cause effective_xcpus value to >>>> differ depending on where exactly it is last computed. Fix this by using >>>> compute_excpus() in this case to give a consistent result. >>>> >>>> Signed-off-by: Waiman Long >>>> --- >>>>   kernel/cgroup/cpuset.c | 14 +++++--------- >>>>   1 file changed, 5 insertions(+), 9 deletions(-) >>>> >>>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >>>> index da2b3b51630e..37d118a9ad4d 100644 >>>> --- a/kernel/cgroup/cpuset.c >>>> +++ b/kernel/cgroup/cpuset.c >>>> @@ -2168,17 +2168,13 @@ static void update_cpumasks_hier(struct cpuset *cs, struct tmpmasks *tmp, >>>>           spin_lock_irq(&callback_lock); >>>>           cpumask_copy(cp->effective_cpus, tmp->new_cpus); >>>>           cp->partition_root_state = new_prs; >>>> -        if (!cpumask_empty(cp->exclusive_cpus) && (cp != cs)) >>>> -            compute_excpus(cp, cp->effective_xcpus); >>>> - >>>>           /* >>>> -         * Make sure effective_xcpus is properly set for a valid >>>> -         * partition root. >>>> +         * Need to compute effective_xcpus if either exclusive_cpus >>>> +         * is non-empty or it is a valid partition root. >>>>            */ >>>> -        if ((new_prs > 0) && cpumask_empty(cp->exclusive_cpus)) >>>> -            cpumask_and(cp->effective_xcpus, >>>> -                    cp->cpus_allowed, parent->effective_xcpus); >>>> -        else if (new_prs < 0) >>>> +        if ((new_prs > 0) || !cpumask_empty(cp->exclusive_cpus)) >>>> +            compute_excpus(cp, cp->effective_xcpus); >>>> +        if (new_prs < 0) >>>>               reset_partition_data(cp); >>>>           spin_unlock_irq(&callback_lock); >>>> >>> The code resets partition data only for new_prs < 0. My understanding is that a partition is invalid >>> when new_prs <= 0. Shouldn't reset_partition_data() also be called when new_prs = 0? Is there a >>> specific reason to skip the reset in that case? >> update_cpumasks_hier() is called when changes in a cpuset or hotplug affects other cpusets in the >> hierarchy. With respect to changes in partition state, it is either from valid to invalid or vice >> versa. It will not change from a valid partition to member. The only way new_prs = 0 is when old_prs >> = 0. Even if the affected cpuset is processed again in update_cpumask_hier(), any state change from >> valid partition to member (update_prstate()), reset_partition_data() should have been called there. >> That is why we only care about when new_prs != 0. >> > Thank you for your patience. > >> The code isn't wrong here. However I can change the condition to (new_prs <= 0) if it makes it >> easier to understand. >> > I agree there's nothing wrong with the current logic. However, for clarity, I suggest changing the > condition to (new_prs <= 0). This allows the function's logic to be fully self-consistent and > focused on a single responsibility. This approach would allow us to simplify the code to: > > if (new_prs > 0) > compute_excpus(cp, cp->effective_xcpus); > else > reset_partition_data(cp); > > Since reset_partition_data() already handles cases whether cp->exclusive_cpus is empty or not, this > implementation would be more concise while correctly covering all scenarios. effective_xcpus should be set when exclusive_cpus is not empty or when the cpuset is a valid partition root. So just checking new_prs for compute_excpus() is not enough. Cheers, Longman >