Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4854473ybl; Tue, 4 Feb 2020 03:14:27 -0800 (PST) X-Google-Smtp-Source: APXvYqyHmmh9hqPL1Ly5B862fy0iFAXT19s6mbrW51vR9ueFotI72PcPgqDhmLTy7KEaWp9npTiG X-Received: by 2002:a9d:7a47:: with SMTP id z7mr22297198otm.179.1580814866989; Tue, 04 Feb 2020 03:14:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580814866; cv=none; d=google.com; s=arc-20160816; b=QZ93jqnHyEUAWLHv3qCP+G9ufONRLLmC4Oi3wZMA0rK4NJRL9hsYIUb7v3a6BRTWED rYBqBnwigK/NfTJBxpoZLEDwvmVyR3eoW9Z/14MseotcclN52Zk8sxt2H8FaZ87bNixj 67S941Ee87Bh84xV2x0Y5wJR4qrShMWMJ7YnLBgY6W9i21yLDyVFwUjlqY+I/FgtL4Zc gH3yrxamJ1jh1WquRknbo7I0e7RWKTB+hs/Mhfmb1woxmFbUYvdzDrXzuXcjFynuhfdq UkZupjj+gLstDJwBe5oIHjlEED/MC/h+qysB5Br8zBh5J3XnCqqVRHy8n35EEuB79+sf 1XAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xm+Fa7oJGBEhM69A1p2kPzMRYERy8PvvMCntWp25boE=; b=nbmCgqiux9tTSqytroSTpqW7RVXzFQUD5NH1jNegQyk26S2c4x63p7NKjsKCVwDxCc ed82NwrMCOFaa0x0y5LfFlne/69D/usdTddMccuhDK/gHbZqxu59H/I5D2AgLHYQaOdJ pVxwbLtC4oYOVGzqGtU3cDhwMZ12mX6zlUSXeC6gYTofBc5Sog5RCHdeAA7du6CtIYy9 RdOHNK2bK3G5+mdFyAWGaVDR8ZBlhO6pkWfB7GEWMLm+VwI1pIwmR+UnF+ldneUGy5QH wW0Cl0b0I2eWIzSUmWW/kXZu7uGyowYA2b6NC+1VQY60hIsdC6/YmpbMWaNN7e3c29Jo 8cQQ== 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 r4si11990532otq.188.2020.02.04.03.14.14; Tue, 04 Feb 2020 03:14:26 -0800 (PST) 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 S1727361AbgBDLNN (ORCPT + 99 others); Tue, 4 Feb 2020 06:13:13 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:47994 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727124AbgBDLNM (ORCPT ); Tue, 4 Feb 2020 06:13:12 -0500 Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iyw8i-0004qC-Ni; Tue, 04 Feb 2020 11:13:08 +0000 Date: Tue, 4 Feb 2020 12:13:07 +0100 From: Christian Brauner To: Michal =?utf-8?Q?Koutn=C3=BD?= Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Tejun Heo , Oleg Nesterov , Ingo Molnar , Johannes Weiner , Li Zefan , Peter Zijlstra , cgroups@vger.kernel.org Subject: Re: [PATCH v5 5/6] clone3: allow spawning processes into cgroups Message-ID: <20200204111307.hxtundpcneju2y7n@wittgenstein> References: <20200121154844.411-1-christian.brauner@ubuntu.com> <20200121154844.411-6-christian.brauner@ubuntu.com> <20200129132719.GD11384@blackbody.suse.cz> <20200202093702.cdlyytywty7hk3rn@wittgenstein> <20200203143228.GC13360@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200203143228.GC13360@blackbody.suse.cz> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 03, 2020 at 03:32:28PM +0100, Michal Koutný wrote: > On Sun, Feb 02, 2020 at 10:37:02AM +0100, Christian Brauner wrote: > > cgroup_post_fork() is called past the point of no return for fork and > > cgroup_css_set_put_fork() is explicitly documented as only being > > callable before forks point of no return: > I missed this and somehow incorrectly assumed it's called at the end of > fork too. I find the css_set refcounting correct now. > > BTW any reason why not to utilize cgroup_css_set_put_fork() for the > regular cleanup in cgroup_post_fork() too? Hmyeah, should be doable if we do: kargs->cset = NULL; cgroup_css_set_put_fork(kargs); Christian