From patchwork Tue Apr 19 02:09:58 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 12817249 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 5CB65C433EF for ; Tue, 19 Apr 2022 02:10:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E0A88D002D; Mon, 18 Apr 2022 22:10:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 968FA8D0026; Mon, 18 Apr 2022 22:10:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 809358D002D; Mon, 18 Apr 2022 22:10:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 6DC4D8D0026 for ; Mon, 18 Apr 2022 22:10:05 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3B18217CC for ; Tue, 19 Apr 2022 02:10:05 +0000 (UTC) X-FDA: 79371998370.03.299C80A Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf29.hostedemail.com (Postfix) with ESMTP id 2E767120008 for ; Tue, 19 Apr 2022 02:10:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650334204; x=1681870204; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=nH/XrxtiTaYfm0g+ofM2ITpPrGvqHIGnxGucWn4QUeE=; b=F2z8daSbqqIafkm32RFuYwkEqWrqQMNC2XLQwca7VOuFBzmb0CruFSak 6MJ/A/EVcu6T8QaE2wJOiEUiOaor86m3pTm3lf9LOUMj8uFp1Z420Oqbi WkV0WNkoqGFpD7dLKiIwdv2eB3/xYMur+AVj7X3M96JuhxJii0exrDbt3 neB4ohzgpLOUdM204cXCRUshtlcoAbLvXNLqW1KqkCaGOMnDKbBDC4KSt 4Pl0bxa8g4Y27Ldy+LccsuOtu6RSe1LKuAgM2IZ9qJhfePhB2a2GjnhVW AXM524T8GqXr1Hf+ZjUP/UJkO2TBmuGfKNF7F4dOhdfcDx6IG0c0oCOzi g==; X-IronPort-AV: E=McAfee;i="6400,9594,10321"; a="243586102" X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="243586102" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Apr 2022 19:10:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,271,1643702400"; d="scan'208";a="665625976" Received: from shbuild999.sh.intel.com ([10.239.146.138]) by orsmga004.jf.intel.com with ESMTP; 18 Apr 2022 19:09:59 -0700 From: Feng Tang To: Zefan Li , Tejun Heo , Johannes Weiner , Andrew Morton , Michal Hocko , cgroups@vger.kernel.org, linux-mm@kvack.org Cc: Dave Hansen , ying.huang@intel.com, Feng Tang Subject: [RFC PATCH] cgroup/cpuset: fix a memory binding failure for cgroup v2 Date: Tue, 19 Apr 2022 10:09:58 +0800 Message-Id: <20220419020958.40419-1-feng.tang@intel.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 2E767120008 X-Stat-Signature: m746b84345ae5qrmu8qwjuwk94hdntda Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=F2z8daSb; spf=none (imf29.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-HE-Tag: 1650334203-907817 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: We got report that setting cpuset.mems failed when the nodemask contains a newly onlined memory node (not enumerated during boot) for cgroup v2, while the binding succeeded for cgroup v1. The root cause is, for cgroup v2, when a new memory node is onlined, top_cpuset's 'mem_allowed' is not updated with the new nodemask of memory nodes, and the following setting memory nodemask will fail, if the nodemask contains a new node. Fix it by updating top_cpuset.mems_allowed right after the new memory node is onlined, just like v1. Signed-off-by: Feng Tang --- Very likely I missed some details here, but it looks strange that the top_cpuset.mem_allowed is not updatd even after we onlined several memory nodes after boot. kernel/cgroup/cpuset.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 9390bfd9f1cd..b97caaf16374 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -3314,8 +3314,7 @@ static void cpuset_hotplug_workfn(struct work_struct *work) /* synchronize mems_allowed to N_MEMORY */ if (mems_updated) { spin_lock_irq(&callback_lock); - if (!on_dfl) - top_cpuset.mems_allowed = new_mems; + top_cpuset.mems_allowed = new_mems; top_cpuset.effective_mems = new_mems; spin_unlock_irq(&callback_lock); update_tasks_nodemask(&top_cpuset);