From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D39FFC6FD1D for ; Fri, 7 Apr 2023 15:31:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233213AbjDGPb0 (ORCPT ); Fri, 7 Apr 2023 11:31:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232333AbjDGPbE (ORCPT ); Fri, 7 Apr 2023 11:31:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C94846A5A for ; Fri, 7 Apr 2023 08:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680881420; 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=5eE8zuLKcMzLpL2FtuAWtdIO+Pdjkebtgu24Aa6llV4=; b=iK2cqat/1HxdjEPmCY/4Iz8jN3u9tMlB34biFOIjmeYkhesgel5aDWszvfvh7FAaW1kgFi OMem8TpMlRtk1EsfikgTIiCS944ZxkM2MGqlMFHS0hb5o5cct7hLKrZbB1wvvqG+KIz+1x Rro8E4+bpVsH8GOcLhhBqQz2IRjKRIA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-383-xkHeZsBvO8SGG0fWPLnAlw-1; Fri, 07 Apr 2023 11:30:15 -0400 X-MC-Unique: xkHeZsBvO8SGG0fWPLnAlw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2870C8996E2; Fri, 7 Apr 2023 15:30:15 +0000 (UTC) Received: from [10.22.33.209] (unknown [10.22.33.209]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6A12B2166B30; Fri, 7 Apr 2023 15:30:14 +0000 (UTC) Message-ID: <89853ab9-7759-11bf-f751-28ce81a4f02e@redhat.com> Date: Fri, 7 Apr 2023 11:30:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 3/3] cgroup/cpuset: Allow only one active attach operation per cpuset Content-Language: en-US To: Christian Brauner Cc: Tejun Heo , Zefan Li , Johannes Weiner , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Juri Lelli , Dietmar Eggemann , gscrivan@redhat.com References: <20230331145045.2251683-1-longman@redhat.com> <20230331145045.2251683-4-longman@redhat.com> <20230406-haselnuss-baumhaus-83dc05f869df@brauner> From: Waiman Long In-Reply-To: <20230406-haselnuss-baumhaus-83dc05f869df@brauner> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/6/23 05:44, Christian Brauner wrote: > On Fri, Mar 31, 2023 at 10:50:45AM -0400, Waiman Long wrote: >> The current cpuset code uses the global cpuset_attach_old_cs variable >> to store the old cpuset value between consecutive cpuset_can_attach() >> and cpuset_attach() calls. Since a caller of cpuset_can_attach() may >> not need to hold the global cgroup_threadgroup_rwsem, parallel cpuset >> attach operations are possible. >> >> When there are concurrent cpuset attach operations in progress, >> cpuset_attach() may fetch the wrong value from cpuset_attach_old_cs >> causing incorrect result. To avoid this problem while still allowing >> certain level of parallelism, drop cpuset_attach_old_cs and use a >> per-cpuset attach_old_cs value. Also restrict to at most one active >> attach operation per cpuset to avoid corrupting the value of the >> per-cpuset attach_old_cs value. >> >> Signed-off-by: Waiman Long >> --- >> kernel/cgroup/cpuset.c | 19 ++++++++++++++----- >> 1 file changed, 14 insertions(+), 5 deletions(-) >> >> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c >> index 2367de611c42..3f925c261513 100644 >> --- a/kernel/cgroup/cpuset.c >> +++ b/kernel/cgroup/cpuset.c >> @@ -198,6 +198,8 @@ struct cpuset { >> >> /* Handle for cpuset.cpus.partition */ >> struct cgroup_file partition_file; >> + >> + struct cpuset *attach_old_cs; >> }; >> >> /* >> @@ -2456,22 +2458,27 @@ static int fmeter_getrate(struct fmeter *fmp) >> return val; >> } >> >> -static struct cpuset *cpuset_attach_old_cs; >> - >> /* Called by cgroups to determine if a cpuset is usable; cpuset_rwsem held */ >> static int cpuset_can_attach(struct cgroup_taskset *tset) >> { >> struct cgroup_subsys_state *css; >> - struct cpuset *cs; >> + struct cpuset *cs, *oldcs; >> struct task_struct *task; >> int ret; >> >> /* used later by cpuset_attach() */ >> - cpuset_attach_old_cs = task_cs(cgroup_taskset_first(tset, &css)); >> + oldcs = task_cs(cgroup_taskset_first(tset, &css)); >> cs = css_cs(css); >> >> percpu_down_write(&cpuset_rwsem); >> >> + /* >> + * Only one cpuset attach operation is allowed for each cpuset. >> + */ >> + ret = -EBUSY; >> + if (cs->attach_in_progress) >> + goto out_unlock; > That'll mean CLONE_INTO_CGROUP becomes even more interestig because it > isn't subject to this restriction in contrast to fork()+migrate, right? This patch is not related to the CLONE_INTO_CGROUP. In fact, I have dropped that in latter version. Cheers, Longman