Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp721104ybp; Fri, 4 Oct 2019 04:02:04 -0700 (PDT) X-Google-Smtp-Source: APXvYqx3NcKekQFdXFATUtUE4sB7CqV4t1B0aQ1dMS6rFNzL8O2y87CUFrgQzlc4+TbWTuh9kwYY X-Received: by 2002:a50:baab:: with SMTP id x40mr14654531ede.60.1570186924134; Fri, 04 Oct 2019 04:02:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570186924; cv=none; d=google.com; s=arc-20160816; b=wnkxAuLVBe5yz1uqlvQZDCkYMwg31/skjLV64KfxEdWLWWdurdg/WYsibg23aHxarN abk0ZhgxwZALCXGTVUWgD64iWEpFH2tikbCbSRu5y5SSHXfUATtcCmtLNJN7r7QhaGHA tDAFFu82knTkMvKx1I2JQ8u+nMVKXKKLaQIGAquZVtnczLC6CMFswsg1uBAp5/VtniEK CKThDfgt1hwYc/I1uMhPdhuGV8RaslNERCnwagnE008RqMn9bEQgmthElLzOYSYLA4q2 LBRqsRVmF49ZoHdEDYhzUqb7Huh8JNVkShxIBaKVWoaVq//6ZpnEh2vlff8PBOq+Wn/Z z2pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=39+7sKjj3zSYUZa3Hdh5s5+QKWboAup4kVCtFn1vxPc=; b=D3Z4M0yi2CnhJP/thfLp3LKw7O7lfS6S0aCG44ZTj1/BA6fn3AMYH9VLjx6uptDvoy kVbKc9FPuXlRM0QRmvA00VLmlRwlzWSvQgdcr3C8HEN0g9PLU0oSc/mPtGHZ3s5vIPwg lEvkJRWhil0zf4WMMNGO6FEDhe5f3C3r3HS1gIeFCQJ5yUdu0QyXE2sdnMfo9A8ZWsQD v+6dYmTFW6c5oDN+cODsdB9VrXlvqcDTNKBW4kBulscsGZP+76DE7qLT2LtRykFWyPZX lUw5+oIok1PHvCepmbjhM+b/wEOyqAJ3A7Fp/u1Jg3zN19RzI93O9Ml1wokLBs3gKLE9 5cQA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8si2756544eju.333.2019.10.04.04.01.39; Fri, 04 Oct 2019 04:02:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729524AbfJDK6F (ORCPT + 99 others); Fri, 4 Oct 2019 06:58:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:55138 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725730AbfJDK6F (ORCPT ); Fri, 4 Oct 2019 06:58:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E917EABC6; Fri, 4 Oct 2019 10:58:02 +0000 (UTC) From: =?UTF-8?q?Michal=20Koutn=C3=BD?= To: cgroups@vger.kernel.org Cc: Tejun Heo , linux-kernel@vger.kernel.org, Li Zefan , Johannes Weiner Subject: [PATCH 1/5] cgroup: Update comments about task exit path Date: Fri, 4 Oct 2019 12:57:39 +0200 Message-Id: <20191004105743.363-2-mkoutny@suse.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20191004105743.363-1-mkoutny@suse.com> References: <20191004105743.363-1-mkoutny@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org We no longer take cgroup_mutex in cgroup_exit and the exiting tasks are not moved to init_css_set, reflect that in several comments to prevent confusion. Signed-off-by: Michal Koutný --- kernel/cgroup/cgroup.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index 753afbca549f..1488bb732902 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -899,8 +899,7 @@ static void css_set_move_task(struct task_struct *task, /* * We are synchronized through cgroup_threadgroup_rwsem * against PF_EXITING setting such that we can't race - * against cgroup_exit() changing the css_set to - * init_css_set and dropping the old one. + * against cgroup_exit()/cgroup_free() dropping the css_set. */ WARN_ON_ONCE(task->flags & PF_EXITING); @@ -1430,9 +1429,8 @@ struct cgroup *task_cgroup_from_root(struct task_struct *task, struct cgroup_root *root) { /* - * No need to lock the task - since we hold cgroup_mutex the - * task can't change groups, so the only thing that can happen - * is that it exits and its css is set back to init_css_set. + * No need to lock the task - since we hold css_set_lock the + * task can't change groups. */ return cset_cgroup_from_root(task_css_set(task), root); } @@ -6020,7 +6018,7 @@ void cgroup_post_fork(struct task_struct *child) struct css_set *cset; spin_lock_irq(&css_set_lock); - cset = task_css_set(current); + cset = task_css_set(current); /* current is @child's parent */ if (list_empty(&child->cg_list)) { get_css_set(cset); cset->nr_tasks++; @@ -6063,20 +6061,8 @@ void cgroup_post_fork(struct task_struct *child) * cgroup_exit - detach cgroup from exiting task * @tsk: pointer to task_struct of exiting process * - * Description: Detach cgroup from @tsk and release it. - * - * Note that cgroups marked notify_on_release force every task in - * them to take the global cgroup_mutex mutex when exiting. - * This could impact scaling on very large systems. Be reluctant to - * use notify_on_release cgroups where very high task exit scaling - * is required on large systems. + * Description: Detach cgroup from @tsk. * - * We set the exiting tasks cgroup to the root cgroup (top_cgroup). We - * call cgroup_exit() while the task is still competent to handle - * notify_on_release(), then leave the task attached to the root cgroup in - * each hierarchy for the remainder of its exit. No need to bother with - * init_css_set refcnting. init_css_set never goes away and we can't race - * with migration path - PF_EXITING is visible to migration path. */ void cgroup_exit(struct task_struct *tsk) { @@ -6086,7 +6072,8 @@ void cgroup_exit(struct task_struct *tsk) /* * Unlink from @tsk from its css_set. As migration path can't race - * with us, we can check css_set and cg_list without synchronization. + * with us (thanks to cgroup_threadgroup_rwsem), we can check css_set + * and cg_list without synchronization. */ cset = task_css_set(tsk); @@ -6102,6 +6089,8 @@ void cgroup_exit(struct task_struct *tsk) spin_unlock_irq(&css_set_lock); } else { + /* Take reference to avoid freeing init_css_set in cgroup_free, + * see cgroup_fork(). */ get_css_set(cset); } -- 2.21.0