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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50C09C433FE for ; Tue, 26 Apr 2022 03:23:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 738CB6B0073; Mon, 25 Apr 2022 23:23:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C1AF6B0074; Mon, 25 Apr 2022 23:23:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 561E56B0075; Mon, 25 Apr 2022 23:23:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 445816B0073 for ; Mon, 25 Apr 2022 23:23:44 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1C3FB2064A for ; Tue, 26 Apr 2022 03:23:44 +0000 (UTC) X-FDA: 79397585568.30.D838503 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf03.hostedemail.com (Postfix) with ESMTP id D11A920032 for ; Tue, 26 Apr 2022 03:23:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650943423; x=1682479423; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=MIZ9NnOqirQrvhaRVQ8rsuasqFgvVqtc65THhom/L0w=; b=MQdwmHRru6rMs2N2w8m1GI0A7+c8FqbFqFQmimR6PNeK6E0zoVIhWOIr +2X7eFNsqU9/88PYTqIXpRqGeOJ39oomxIEYXhcQl4aNJn3GGy4kkgKiu VVQSTI1k3BqtNlbKBQe8ilLd1v0kaeI75gGZsQ+0ScygxR7ysQWqBe8gc dCB31BMgpM/L6mfGWPx+cNOwXWN36qT4v+ah5e6vtubQFZ/55+rg8Ful+ ORgO2cZg6DTc3LNpfxLcTXPDiE2MeDh9qJw79dwU5/DO2hO3LgE6/i9ui GPcJ2fm8eYnG7Y+B04dv1rKWvqqjpwzGdI93MSxk6+1WjURH2R8emzlHF Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10328"; a="245359070" X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="245359070" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Apr 2022 20:23:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,290,1643702400"; d="scan'208";a="579644855" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.146.138]) by orsmga008.jf.intel.com with ESMTP; 25 Apr 2022 20:23:37 -0700 Date: Tue, 26 Apr 2022 11:23:37 +0800 From: Feng Tang To: Waiman Long Cc: Tejun Heo , Zefan Li , Johannes Weiner , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Michal Hocko , Dave Hansen , ying.huang@intel.com, stable@vger.kernel.org Subject: Re: [PATCH v2] cgroup/cpuset: Remove cpus_allowed/mems_allowed setup in cpuset_init_smp() Message-ID: <20220426032337.GA84190@shbuild999.sh.intel.com> References: <20220425155505.1292896-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220425155505.1292896-1-longman@redhat.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D11A920032 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MQdwmHRr; spf=none (imf03.hostedemail.com: domain of feng.tang@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=feng.tang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Stat-Signature: x4jzt8p9mwqaaa3itzz74tci9ojk9tzg X-HE-Tag: 1650943419-634571 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Waiman, On Mon, Apr 25, 2022 at 11:55:05AM -0400, Waiman Long wrote: > There are 3 places where the cpu and node masks of the top cpuset can > be initialized in the order they are executed: > 1) start_kernel -> cpuset_init() > 2) start_kernel -> cgroup_init() -> cpuset_bind() > 3) kernel_init_freeable() -> do_basic_setup() -> cpuset_init_smp() > > The first cpuset_init() function just sets all the bits in the masks. > The last one executed is cpuset_init_smp() which sets up cpu and node > masks suitable for v1, but not v2. cpuset_bind() does the right setup > for both v1 and v2. > > For systems with cgroup v2 setup, cpuset_bind() is called once. For > systems with cgroup v1 setup, cpuset_bind() is called twice. It is > first called before cpuset_init_smp() in cgroup v2 mode. Then it is > called again when cgroup v1 filesystem is mounted in v1 mode after > cpuset_init_smp(). > > [ 2.609781] cpuset_bind() called - v2 = 1 > [ 3.079473] cpuset_init_smp() called > [ 7.103710] cpuset_bind() called - v2 = 0 I run some test, on a server with centOS, this did happen that cpuset_bind() is called twice, first as v2 during kernel boot, and then as v1 post-boot. However on a QEMU running with a basic debian rootfs image, the second call of cpuset_bind() didn't happen. > As a result, cpu and memory node hot add may fail to update the cpu and > node masks of the top cpuset to include the newly added cpu or node in > a cgroup v2 environment. > > smp_init() is called after the first two init functions. So we don't > have a complete list of active cpus and memory nodes until later in > cpuset_init_smp() which is the right time to set up effective_cpus > and effective_mems. > > To fix this problem, the potentially incorrect cpus_allowed & > mems_allowed setup in cpuset_init_smp() are removed. For cgroup v2 > systems, the initial cpuset_bind() call will set them up correctly. > For cgroup v1 systems, the second call to cpuset_bind() will do the > right setup. > > cc: stable@vger.kernel.org > Signed-off-by: Waiman Long > --- > kernel/cgroup/cpuset.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > index 9390bfd9f1cd..6bd8f5ef40fe 100644 > --- a/kernel/cgroup/cpuset.c > +++ b/kernel/cgroup/cpuset.c > @@ -3390,8 +3390,9 @@ static struct notifier_block cpuset_track_online_nodes_nb = { > */ > void __init cpuset_init_smp(void) > { > - cpumask_copy(top_cpuset.cpus_allowed, cpu_active_mask); > - top_cpuset.mems_allowed = node_states[N_MEMORY]; So can we keep line cpumask_copy(top_cpuset.cpus_allowed, cpu_active_mask); and only remove line top_cpuset.mems_allowed = node_states[N_MEMORY]; ? Thanks, Feng