From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.222 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792648238; b=Wn8s8cdbqNRz0KE5VowWbPjbnvft/5RCKa4sGwBbM7oJxTp/eep5ArH9/h/BGxl2iyip 3dKEwULhMBXwPEp3t6fY2MTTBicAu+ecpF/9xZf7YVcQuli4uMZlUYgEBLUarpCgzWhCv rJfumX00FLEWtqMIXRTM/EW+WN6lbUjSSDP3ishkqX76wCE4Qwp46UBwA+wkuTyMSw1rU 0X45ZTw0gcdtpZVMa+8VLSSxxl4PFpi4RziqzK/8q33Mnk/+mXnnLoUtHdLTSuhy6KcaU 19WM6iqI9hEGkps6TniMHAp0P4bfMevdKHXuK7MliW+vlxH7HEnPUL9iyebjraCkZYw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792648238; 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=ehflWP/cfb3SeLIRWXb/gzDzyWPbV1lMgr0T0r9SCN8=; b=d98zpoN7qprPGG/ztl+IZuBsfl772HjixfFNCtAHhH4eQv3OBM401xDwztRhPBDnLOkW 1rzY31OEYrncC7VoNASE4x5/N2ZwTdDtZegQD9ECayvzJXfCTzx0HN1x2TAzULy1JFyFp EO1f+1k9zQVPdG7AQqZ9kPtIY6PKPa97FuGk2Jff4++fUf4UOyTfpS5AC7JnzHD+6MtBR HaLin78b+UcxdGZIRs8Jk8vnZTs9P6aGzy9aumQ1mtYBZEC3DTFyKmNd//XWrcbaIPL5W /wg3pMmaTURlvDMAybWtLzYzxFM8seBR5ghW1yk+J7zqtVkECq5v4Ys+G2XLjJI+OqQ== 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=MSqEqIGa; arc=none smtp.remote-ip=91.218.175.222 Received: from mta0.migadu.com (out-222.mta0.migadu.com [91.218.175.222]) (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 C9FBB606A31A for ; Thu, 22 Oct 2026 05:50:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org C9FBB606A31A 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=MSqEqIGa X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=LQijZitfScP4O3BlAnhn6TsBqQiTt58EcetEfGwmwI0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792648234; v=1; x=1793253034; b=MSqEqIGavKMN4+Q9RPp6F86JLAaxsNb40VU4XJl8eVXW2mxs0+3gpVAj0MGVnY00+whcJqlH rg9/+FvlVFM4iCNt3R6WOD+zmueiEWJHnZ4OXORfDoPTrOYZib85zeS145n30puRxY3cG8VAb4M V8CQMTGrtZ3cF5O5hQ+8542I= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id fe7f562c755d7731; Thu, 22 Oct 2026 05:50:34 +0000 X-Mizu-Trace-ID: fe7f562c755d7731 X-Migadu-Flow: FLOW_OUT Message-ID: <6bbd6b27-a417-436e-aeba-1199626c3c6f@linux.dev> Date: Thu, 22 Oct 2026 13:50:24 +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 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition To: Waiman Long , Tejun Heo , Ridong Chen Cc: Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Guopeng Zhang References: <20261010075947.333549-1-guopeng.zhang@linux.dev> <20261010075947.333549-2-guopeng.zhang@linux.dev> <0514f986-c125-4a2a-8079-cbbfe5cdc273@redhat.com> Content-Language: en-US From: Guopeng Zhang In-Reply-To: <0514f986-c125-4a2a-8079-cbbfe5cdc273@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 在 2026/10/22 11:23, Waiman Long 写道: > On 10/10/26 3:59 AM, Guopeng Zhang wrote: >> From: Guopeng Zhang >> >> When the CPU list of a remote partition is reduced, a removed CPU may >> remain unavailable to the top cpuset. >> >> This can be reproduced on a cgroup v2 system with CPUs 0-7 online: >> >>      cd /sys/fs/cgroup >>      echo +cpuset > cgroup.subtree_control >>      mkdir A >>      echo 1-7 > A/cpuset.cpus >>      echo 1-7 > A/cpuset.cpus.exclusive >>      echo +cpuset > A/cgroup.subtree_control >>      mkdir A/B >>      echo 1-4 > A/B/cpuset.cpus >>      echo root > A/B/cpuset.cpus.partition >>      echo 1-3 > A/B/cpuset.cpus >>      cat cpuset.cpus.effective >> >> The last command should show 0,4-7, but CPU 4 is missing. >> >> update_cpumask() calls partition_cpus_change() while cs->cpus_allowed >> still contains the old mask. remote_cpus_update() first releases CPU 4, >> but the hierarchy update revisits B and compute_excpus() still sees the >> old mask, so CPU 4 is removed from the top cpuset again. >> >> Move the cpus_allowed update before partition_cpus_change() so that >> the hierarchy update sees the new mask when it revisits the cpuset. >> >> Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition") >> Signed-off-by: Guopeng Zhang >> --- >>   kernel/cgroup/cpuset.c | 5 ++++- >>   1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index 0ebba2d646c3..de7553459adc 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -2478,10 +2478,13 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs, >>        */ >>       force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus); >>   +    spin_lock_irq(&callback_lock); >> +    cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed); >> +    spin_unlock_irq(&callback_lock); >> + >>       partition_cpus_change(cs, trialcs, &tmp); >>         spin_lock_irq(&callback_lock); >> -    cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed); >>       cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus); >>       if ((old_prs > 0) && !is_partition_valid(cs)) >>           reset_partition_data(cs); > > Sorry for the late reply. > > Thanks for reporting this problem. I suspect similar problem may exist with change to cpuset.cpus.exclusive as well. The root cause of this problem is the recursive call to remote_cpus_update() with the second call missing information leading to the revert of the first call. I have posted another patch to address this recursive call problem. Please take a look to see if you agree with that or not. > Thanks for the explanation and for looking further into the root cause. I'll take a look at your patch and run some local tests once I've taken care of some urgent work. Thanks, Guopeng