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.133.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 D2AD430C345 for ; Thu, 25 Jun 2026 18:16:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782411404; cv=none; b=Gyg7orERgcPjDzisWLNVJKIQsohi4FyOsdZztaZ7NjKh4mO5UrzX2hU0GP6TEYbaZ4M9hb1s5Knu7TeIelkquFmK+x8p79G5Qy61D5C/TsgxpA2P5Y044vaa+8yNelgHWH6UM4FluGYM0be2PbekyiWx0c5Fb8XqdwwQHkl/4rI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782411404; c=relaxed/simple; bh=OOzYeFeHgx2NjYa2M4QmT8jR1s5xc1DsWFy6DBpy7Qo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eIBolI0qaXHf/ed3JQVyjkqvqnHGbuH8XnUjKtoyB4F/um01/Lg97KNGDsovnqh+H2cGzGHBXSCaMPx4s4keozuzC7jCcoc1sDru1jIITw6QkaY71ACqNciJGlPdJP/gZTvxZs3eBYfKRhjjLPqhcNPGnXK7O5AbwHJGH9cHFsE= 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=SpEWHkRB; arc=none smtp.client-ip=170.10.133.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="SpEWHkRB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782411401; 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=nezZbQ4mDiIGlaszHg3bTDzadhMguHC8uLssvhbipdQ=; b=SpEWHkRBA+60dfhYD7zSUDN4pTwlMb/xy7wSX8Wq+2zCUYHP+dwjKrYtOJEFi90ZAexgAu x6+jCCajlB0Q994lDXXJNsu51uUvQIiEi2rOKxsnyW88tjf2mTR9ROY9ED2t//9aNrfo0x U7+s4yAAC8878kAlzqqvdYEPRD0FA9w= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-132-wkerWP-6Plea7xxa4o-Tgg-1; Thu, 25 Jun 2026 14:16:37 -0400 X-MC-Unique: wkerWP-6Plea7xxa4o-Tgg-1 X-Mimecast-MFC-AGG-ID: wkerWP-6Plea7xxa4o-Tgg_1782411394 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 12A1E195419B; Thu, 25 Jun 2026 18:16:33 +0000 (UTC) Received: from [10.2.16.32] (unknown [10.2.16.32]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0A23231D2; Thu, 25 Jun 2026 18:16:28 +0000 (UTC) Message-ID: <5ec570e1-6a4d-4fa4-8827-c586902d99d9@redhat.com> Date: Thu, 25 Jun 2026 14:16:27 -0400 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 v7 3/9] cgroup/cpuset: Prevent race between task attach and cpuset state change To: Ridong Chen , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Li Zefan , Farhad Alemi , Andrew Morton Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Aaron Tomlin , Guopeng Zhang , Gregory Price , David Hildenbrand References: <20260621032816.1806773-1-longman@redhat.com> <20260621032816.1806773-4-longman@redhat.com> <44da924b-f3a1-4ef8-9113-37d6d11b8c1b@linux.dev> Content-Language: en-US From: Waiman Long In-Reply-To: <44da924b-f3a1-4ef8-9113-37d6d11b8c1b@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 On 6/21/26 10:21 PM, Ridong Chen wrote: > > > On 6/21/2026 11:28 AM, Waiman Long wrote: >> Commit e44193d39e8d ("cpuset: let hotplug propagation work wait for >> task attaching") was introduced to let hotplug operation to wait >> until the completion of task attaching operation. However, it is >> still possible that the states of the source or destination cpuset >> can be changed between the cpuset_can_attach() call and the subsequent >> cpuset_attach()/cpuset_cacnel_attach() call. >> >> As a result, data gathered during cpuset_can_attach() cannot be reliably >> used in the subsequent cpuset_attach()/cpuset_cacnel_attach() >> call at all. Make the task attach operation more robust >> and allow the sharing of data between cpuset_can_attach() and >> cpuset_attach()/cpuset_cacnel_attach() by making cpuset_write_resmask() >> and cpuset_partition_write() wait for the completion of task attach >> and set the attach_in_progress flag in the source cpuset as well. >> >> The comments about validate_change() are no longer valid as it won't >> be called at all if an attach operation is in progress. So the comments >> can be removed. >> >> Signed-off-by: Waiman Long >> --- >>   kernel/cgroup/cpuset.c | 28 ++++++++++++++++++++-------- >>   1 file changed, 20 insertions(+), 8 deletions(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index a1c8890d3519..65d095dcada1 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -3080,11 +3080,8 @@ static int cpuset_can_attach(struct >> cgroup_taskset *tset) >>       cs->dl_bw_cpu = cpu; >>     out_success: >> -    /* >> -     * Mark attach is in progress.  This makes validate_change() fail >> -     * changes which zero cpus/mems_allowed. >> -     */ >>       cs->attach_in_progress++; >> +    oldcs->attach_in_progress++; > > I only see oldcs->attach_in_progress being incremented here — the > matching decrement seems to land in a later patch. That makes this one > unbalanced on its own (the count would leak, and a later write to the > source cpuset would block on the new wait_event()), so it's not > bisect-safe. > > Let's either keep the patch self-contained or fold it into the patch > that adds the decrement. Yes, it should have a matching decrement there. Anyway, I am going to revamp this patch to make attach_in_progress flag global instead of per cpuset. This is to make sure that a task attach operation will not race with any cpuset control file write operation. Cheers, Longman