From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B5CC175A66 for ; Tue, 23 Jun 2026 16:16:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782231374; cv=none; b=GY2OKjARG+wdsMN5q7Af7fWGB7xj+s/DWaYI8kKIimyYcr801hQM+IQNjGkLQak0L7k1dPHT9Sajr6fIjoJUyWWOhYoKGIjSysqphBGtuzstu2g8ZsYxWRSHVMdpR/c05E6HlZCwIPSRqfhHNal3ddAJmv7FiuQehVHA1lLyVu8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782231374; c=relaxed/simple; bh=FEp+yKhN/uwAF92BEizkdUUute3l/a/GJYHsqyGEw+I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l2UOMWbQukVg656wduSGV9UdyLd+BMP+fVxlwrSWgrGhqS+n2IqbQP4t7CPnsCxWqo+Txp7evff/OBL5F71Oy5wIpQ4wWyjdhHzNtI7ICIcWfpi7o2ySD5IsGO0jL7TUNDbx/UnzSiA6R50HQxqooU6uNI8u5345mmFibbWd+Xg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=N6ULFb5o; arc=none smtp.client-ip=209.85.167.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="N6ULFb5o" Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-4863a7dac63so52202b6e.1 for ; Tue, 23 Jun 2026 09:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782231372; x=1782836172; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RxkL22KDxjMJAOjKoz1/zPseOPibb81DxVe3Y2gr7ds=; b=N6ULFb5oxq1/jjPgHRBuVVhm9KF6s/htTM/T2KDkbXGylN+I34Exbf5wInRy1svR+q NQkFKr/ennDbxHXBpvF4t0zTbtiJGD+a5wdxziYIvbCynrdtZcZ8EGa5CVfkwhvfu0Lb ZiM+1jcPb1FgNMNGqYfrDdeFKURNMrT9eGl+Y881xCf3uFxeZBcSU9wJ3W/bFKj9m/wx RkL08aW2R18PhHsy22ok/SDJPN3UxEuu/t/n0ltaAgYvluJCZQXTFtW3yPWz/FJD6vHd yy1XF/AEzbedxObyTGB5T7qMqO3MTxhkOQYczmVt+0qzTV8bLsH+N8Xm/tdzEFqcV9TM OCUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782231372; x=1782836172; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RxkL22KDxjMJAOjKoz1/zPseOPibb81DxVe3Y2gr7ds=; b=qOiA777Db06YHGAdkPDmh+n6QeINsSX1Wr7JukrPpU6h4HS0xzna4AT6zDRhfHArsT Xir2HB2F84L/0Xnp6PJCfiMel26tHMObTXEx0sBBUBfIRwW0LCTvjJLPxLYgI70lHFf/ X3GEhjPiOq7FwxZrgBsjpXf7CnbIEwCyZuVAfbDPn3x1WK/rDPHkdN43jk8a0jjJhQcT rSuG/m0UOKFO49PSipEIx3b/3JsW1svbO7u//mvBSXDACu3u7CRoCYTU+YxpI56I7lNf Lpy37qcMLONU4v2tpSaA4p/8SsxMcMLGxP5MFDINy9o8F0OaVsyoXGOvzeTqP2qgK+5H Xalw== X-Forwarded-Encrypted: i=1; AFNElJ99+uNa9SxD7ZuU+NSabbTCfxgRhWm9m9oW196Xhn3fK2Vpe4EJRv+xcxzBM0kP1U3XZZ4wZxr+FIdxVfc=@vger.kernel.org X-Gm-Message-State: AOJu0YwpneS20WLyZUHEeDPHPGzO258RAWzH6Kv9HKfcIPkNNBq1zghA eMYFMn0mdqf8E6NYeS1Lv1lfZFSAjEGXppwpEnl43lKeTWkLbYwbu/k1VMytyY8qjAQ= X-Gm-Gg: AfdE7cmxURw/GR/A3TOaBd463hGHy+BdyzAQ5tmWWa29JlIA4mLtOVFdqXt0o8cc94P Kk2EZieYROq0TqSvkraCVR5l8R+BHRpCGlMMHzk0Tg6Tn92VVH1TcayeijPgA1R/Ntz0QUAmHbq yUUOm5SPusVD2i2eKu3dUcfCqlI6g2VubQPBirsBKK+2d9P+/5Tw4vYzg1pX1PYOOMoxjyLeqZp Og7ttXKO//vWPDAXgyHrj1o91jofrpSVTE/arsmzDdvqnHir2+onc/nMeyLtshds644Lm85oCNC itvSzniW2eVI8iKYS4A2xDB6Ai2s2h6LJ0Bo/i1xJevWt4nLy69Q+pQ3mGPhM3Y8rnGB8CguGLB fg3GRT6o94wufRnSENsN4NvjLF0nEtHUDaZDSZzteIkqmDDLYqQk2v7czYPcIriZQDtXGIDcMKQ Q3SFXRhXkv2vI6mvTyQqJpV+yN5pWxNpzBqdLtMPoFFgpwT4CDi1EDTmgLLWeI+xpBAtWQvCkXO CQsDsg= X-Received: by 2002:a05:6808:1513:b0:48d:e956:e3cf with SMTP id 5614622812f47-48de956f997mr6499808b6e.29.1782231371341; Tue, 23 Jun 2026 09:16:11 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8df81cdf302sm134046626d6.30.2026.06.23.09.16.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 09:16:10 -0700 (PDT) Date: Tue, 23 Jun 2026 12:16:06 -0400 From: Gregory Price To: Waiman Long Cc: Ridong Chen , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , Li Zefan , Farhad Alemi , Andrew Morton , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Aaron Tomlin , Guopeng Zhang , David Hildenbrand Subject: Re: [PATCH v7 2/9] cgroup/cpuset: Fix node inconsistencies between cpuset_update_tasks_nodemask() and cpuset_attach() Message-ID: References: <20260621032816.1806773-1-longman@redhat.com> <20260621032816.1806773-3-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260621032816.1806773-3-longman@redhat.com> On Sat, Jun 20, 2026 at 11:28:09PM -0400, Waiman Long wrote: > Whenever memory node mask is changed, there are 4 places where the node > mask has to be updated or used. > 1) task's node mask via cpuset_change_task_nodemask() > 2) memory policy binding via mpol_rebind_mm() > 3) if memory migration is enabled, migrate from old_mems_allowed to > the new node mask via cpuset_migrate_mm(). > 4) setting old_mems_allowed > > These memory actions are done in cpuset_update_tasks_nodemask() and > cpuset_attach(). However there are inconsistencies in what node masks > are being used in these 2 functions. > > In cpuset_update_tasks_nodemask(), > - cpuset_change_task_nodemask(): guarantee_online_mems() > - mpol_rebind_mm(): mems_allowed > - cpuset_migrate_mm(): guarantee_online_mems() > - old_mems_allowed: guarantee_online_mems() > > In cpuset_attach(), > - cpuset_change_task_nodemask(): guarantee_online_mems() > - mpol_rebind_mm(): effective_mems > - cpuset_migrate_mm(): effective_mems > - old_mems_allowed: effective_mems > > These inconsistencies dates back to quite a long time ago and it is > hard to say what should be the correct values. > > The guarantee_online_mems() function returns a node mask from current or > an ancestor cpuset that is a subset of node_states[N_MEMORY]. Nodes in > node_states[N_MEMORY] are all online, i.e. in node_states[N_ONLINE]. > However, node in node_states[N_ONLINE] may not have memory. So > node_states[N_MEMORY] should be a subset of node_states[N_ONLINE]. > > The guarantee_online_mems() function should mostly be useful for v1 > where mems_allowed is the same as effective_mems. With v2, the memory > nodes in effective_mems should be a subset of node_states[N_MEMORY] > except when a memory hot-unplug operation is in progress and a memory > node is removed from node_states[N_MEMORY] but not yet reflected in > the effective_mems's as cpuset_handle_hotplug() has not been called > from cpuset_track_online_nodes(). > > Let use the following setup for both of them and make them consistent. > - cpuset_change_task_nodemask(): guarantee_online_mems() > - mpol_rebind_mm(): effective_mems > - cpuset_migrate_mm(): guarantee_online_mems() > - old_mems_allowed: guarantee_online_mems() > > So for v2, it is effectively all effective_mems most of the time. For > v1, mpol_rebind_mm() uses mems_allowed which may differ from what > guarantee_online_mems() returns, but it conforms to what the cpuset v1 > documentation says with respect to setting memory policy. > > Reviewed-by: Ridong Chen > Signed-off-by: Waiman Long > --- > kernel/cgroup/cpuset.c | 30 ++++++++++++++++++------------ > 1 file changed, 18 insertions(+), 12 deletions(-) > Reviewed-by: Gregory Price