From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.9 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792675519; b=aD+tFpMAaJFbS1eg2GEidxHnWzymQIJ6hBuwyiMbdWA0eDlJJMl/pKLEiikFKPT3LHXo SfqQ3IdYIXlyDdGtVy0yF/N19ioVJb1cTSySnqFovrex7QvCROdH+rYsodt5Xcx2t/JKz NVVQPwnR13G0+fB1aAyY6eRMlwzueHlMwKCMKKbRy6NUOnUWqUPPZ33sONbhrD32LB3qr QFRc9j7yB2LbmEbAUX/01aknbAdCcqRUOif0WPn3zCFlzaX+8V0i+Gu8SViTUnNv71VRm HCR5X173DW0L7k/zbc2ffyJqloWM2nGKVIaso/gA8vlRKLv6PqbzikxMOxkYfftLQ9g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792675519; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:Content-Language:From:In-Reply-To: Content-Type:Content-Transfer-Encoding; bh=WLw0FxymoDZWDnAnahD4EE413i9SFzx6SNYgZ//FHvM=; b=OVFTOVk4+iGVVBjL9kZE9yLe/8x3Y7teYCo8anE2EPtsd/rZ/61bBwNYEFGDyvsRWeHR drHGWCXrEipxnznSgjBakA/kTsSpd9cSoxq8w9zD0cQZmqQsgof9lJ/VaxhERL1H7qb1o 3OUMV0JWa18nB+pLW/A/99frNUlHnF8YD7Votd4L2PrX6TWNQLyY65xCYdOlN9fROPh+a h6cq0UAeYcFB6PguR80CYPZLv5vFjCMBk6PCg5GpDshQSyFhamKm2rC71JjhlA3hGRFZr tG8oT16eKEFdFrhuco8g4jjOrfEGZRxG1vxbk6AEPhjhkQjUB2MFmtcMqAbjfMcYWCg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b="Ea/WXz/p"; arc=none smtp.remote-ip=91.218.175.9 Received: from mta0.migadu.com (out-9.mta0.migadu.com [91.218.175.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DD2E606A31A for ; Thu, 22 Oct 2026 13:25:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 0DD2E606A31A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=Ea/WXz/p X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=dEUuMsEDkPcNR0+ybxJkBscqRakXtKiVLQf65lFh56o=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792675515; v=1; x=1793280315; b=Ea/WXz/p6/yqS2B7k0cf1z5dg2SXouWyXlIEib7ih45CJ+tAEk+knn5s2IW/Rq2iLRHRzxMN 0GycLD/cjAGT9dmPnyNw1Bozsi3AQ41jFnqM2yTEKs8PL3Y4NaNMdteNm4GbHUR8zEuZucOXI5s 0Hed0E9e5PbDWqde0JaR9Tg0= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id d436972b123e7eba; Thu, 22 Oct 2026 13:25:11 +0000 X-Mizu-Trace-ID: d436972b123e7eba X-Migadu-Flow: FLOW_OUT Message-ID: Date: Thu, 22 Oct 2026 21:25:06 +0800 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH-next 1/6] cgroup/cpuset: Find furthest isolated ancestor for invalidated isolated partition To: Waiman Long , Ridong Chen , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Shuah Khan Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20261022031643.1351877-1-longman@redhat.com> <20261022031643.1351877-2-longman@redhat.com> Content-Language: en-US From: Guopeng Zhang In-Reply-To: <20261022031643.1351877-2-longman@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 在 2026/10/22 11:16, Waiman Long 写道: > Commit 46b885416c27 ("cgroup/cpuset: Fix a missing isolated_cpus > update in update_cpumasks_hier()") searches for the closet partition > root ancestor to determine if the isolated CPUs in a to be invalidated > isolation partition should be removed from isolated_cpus or not. > > As reported by sashiko, this method may not work when there is a deeply > nested isolated partition hierarchy. For instance, Consider a nested > hierarchy A0 -> A1 -> A2 -> A3 where all four are PRS_ISOLATED: > > A0: effective_xcpus = 0-4 > A1: effective_xcpus = 1-4 > A2: effective_xcpus = 2-4 > A3: effective_xcpus = 3-4 > > When A1 shrinks its exclusive_cpus from 1-4 to 1-2, A2 will update it > effective_xcpus to 2. A3 will find its closet partition root ancestor > A2 and decides that its effective_xcpus 3-4 should be removed from > isolated_cpus which is incorrect. > > Address this corner case by searching for the furthest isolated partition > root ancestor instead to decide if its isolated CPUs should be returned > to isolated_cpus. > This looks good to me. Would it be worth adding a test case for the scenario described above, something like: # A middle isolated parent shrunk below coverage: the released # CPUs of the invalidated child stay isolated as a higher # ancestor still covers them. " CX0-4:P2 CX2-4:P2 CX3-4:P2 . . X2 . . 0 A1:0-1,3-4|A2:2|A3:2 A1:P2|A2:P2|A3:P-2 0-4" Reviewed-by: Guopeng Zhang Tested-by: Guopeng Zhang Thanks, Guopeng > Fixes: 46b885416c27 ("cgroup/cpuset: Fix a missing isolated_cpus update in update_cpumasks_hier()") > Signed-off-by: Waiman Long > --- > kernel/cgroup/cpuset.c | 36 +++++++++++++++++------------------- > 1 file changed, 17 insertions(+), 19 deletions(-) > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > index 585a982249ad..7ead8c3b7974 100644 > --- a/kernel/cgroup/cpuset.c > +++ b/kernel/cgroup/cpuset.c > @@ -2156,22 +2156,20 @@ static void compute_partition_effective_cpumask(struct cpuset *cs, > } > > /* > - * ancestor_partition - Find and return the closest valid partition root ancestor > + * iancestor_partition - Return furthest isolated partition root ancestor available > * @cs: the current cpuset > - * > - * Return: The closet partition root ancestor cpuset > + * Return: The furthest isolated partition root ancestor available or NULL if > + * not found. > */ > -static struct cpuset *ancestor_partition(struct cpuset *cs) > +static struct cpuset *iancestor_partition(struct cpuset *cs) > { > struct cpuset *ancestor = parent_cs(cs); > + struct cpuset *iancestor = NULL; > > - /* > - * The top_cpuset is always a valid partition root which will stop > - * the loop if it is reached. > - */ > - while (!is_partition_valid(ancestor)) > - ancestor = parent_cs(ancestor); > - return ancestor; > + for (; ancestor; ancestor = parent_cs(ancestor)) > + if (ancestor->partition_root_state == PRS_ISOLATED) > + iancestor = ancestor; > + return iancestor; > } > > /* > @@ -2283,23 +2281,23 @@ static void update_cpumasks_hier(struct cpuset *cs, struct tmpmasks *tmp, > * For a to be invalidated isolated partition, > * its isolated CPUs may or may not need to be > * removed from isolated_cpus depending on if > - * its closest partition root ancestor is a root > - * or isolated partition. With a PRS_ISOLATED > - * ancestor, the CPUs are checked against its > - * effective xcpus to see if any of them needed > - * to be removed. > + * there is a furthest isolated partition root > + * ancestor available. When such a PRS_ISOLATED > + * ancestor is available, the CPUs are checked > + * against its effective xcpus to see if any of > + * them needed to be removed. > */ > if (is_partition_valid(cp)) > new_prs = -old_prs; > > if (old_prs == PRS_ISOLATED) { > - struct cpuset *ancestor = ancestor_partition(cp); > + struct cpuset *iancestor = iancestor_partition(cp); > > - if (ancestor->partition_root_state == PRS_ROOT) > + if (!iancestor) > del_cpus = cp->effective_xcpus; > else if (cpumask_andnot(tmp->delmask, > cp->effective_xcpus, > - ancestor->effective_xcpus)) > + iancestor->effective_xcpus)) > del_cpus = tmp->delmask; > > if (del_cpus) {