From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (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 B6D7E3D88E5 for ; Wed, 10 Jun 2026 11:34:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781091256; cv=none; b=qkJpU4x+6U2nWOKZ4/A6Nl+mombYykeInpiirsus8y76bgPoyeQpgYyBw2CoZ4qS9+pBaW4AgY7DYN5Auq7F2gbCy7Y6Ddm/NuoTfo5ifPkHhGccm81rTY2luNAQngf5dVhPbIi/p+LGQh3+PilJjJDHbl5vExjSaYXik+dThaI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781091256; c=relaxed/simple; bh=x+F2KXtZ3AnoeA2HgEo4T3r8Mhf5qGBjX2zVqGVu+F4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dxNm6CKw+oG5tRzXrElKGWQMGTfyljEoa5M9w+GxsxKK6m8nc6wKADarN1+WDRcGeW2aw38g0VaYv5vLTsz7Mqkfu4wnWiCgUap2sAoVs5CZ0J6TlbJo2CqzTBpvIzADnh3yMdKMI9WHRF1//zlAhMOoJXK/O3KvLF6kyrNxcl8= 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=TkVnRhQO; arc=none smtp.client-ip=209.85.219.47 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="TkVnRhQO" Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-8ce9ddeddefso71642246d6.0 for ; Wed, 10 Jun 2026 04:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1781091254; x=1781696054; 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=ojEE6G7x5Hyz18bffBqmv/qKtAjxoG29cTYIDqTjZjM=; b=TkVnRhQOheaFAt1gnoN6Hm6e7ZI73qtlI/OTAapfcVVpOcZTGyBfKZpk9Tu0CN3Pf5 N2XdfGhogTuXo0rOwhstopK4jZaUj7DZCoz+F5nibrgF/rn5wdZImS2JSuaZLj+f5zMH eqGiVRwTRy8x6GxMuWk4IQDWV23DjhrEWnlIzU0xO0qwhLkOd9U+ujuys1Dfj/i6dWoH eOyjRmKHGd7swRgX8SAqc1kOhmR10rnrw670mDgJLq5t2mwxsZLB6AE3v6bJCG/53Rla SswirCsJYZyK5SGIeTLdHO6en1qqrZKgGc8L4wp20EZmdI3uXoKfIB8/NzpDNCQbUyQd 1nNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781091254; x=1781696054; 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=ojEE6G7x5Hyz18bffBqmv/qKtAjxoG29cTYIDqTjZjM=; b=pQQ1G4vyl/AMnXXfegkJ66wBcrb4GsAGZ6aGqNs4tMbf81AaX37K3QAq0Ea3dxeqGY GqeIYpky7qfISEPx5M01HxswH1rclr/a3MXmjQtzM7eVBwkHf2DS6QkG+U2zMWEGdLY0 Dp7E4almj5Yc/1j2Nr2vINq9dfj+5KllV4pEJqYCTojgBnaf4Tm30uhELerSoB7bRF2m A3k0i0m35nksNBjQSLgCK1W9F3cc1pIkHUXI8uFDQxB35wFXlQfDS/3kDB62LP4e6Vlo UsKS1BlRVgH69vDSqay3xyhhW/kr5Z9KQRw3W8bPulBIbhDsULk5LQoWf5eKHoPCFcEj l/ew== X-Forwarded-Encrypted: i=1; AFNElJ9YFrBT8nuEV8HlvbRt+96L2y3tJqOE0Q+/FUL7ZhGcbo8NdVAHE8pBAzhyScZ77pNRbWXaMpRK+NnbYyQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwSrjuVxgg9M/S+Z5MQR0rWjy1Qi7u0zgy15PH2GbQwg02LVbyt K2C1pCw6y5ISff6Mv+kZP+h1bY9beG87hz1Oin/Zx41qYbp8ZkDnium+WbZM78wdxyE= X-Gm-Gg: Acq92OH802Wo75az3o4u+3RwNIcqNP1gjxNbid9Zb4dsbb+La4OYwiV0B1oE67CoCpE 2XFeH6Gg9FJTG5hucWrjK16L6YIBCcpX6d9uIa5bPL3Ar/UdXw9FjhR/w92O2st52bX4a2pCXO2 wYBPptaqRtbk4oZo9U+3I+d51PiU7wbU6+R5o1blmCxaEM0DWFZ3KFWyZYz17LQHn1QSKf+sYf5 pxd02Wk9i48zKJHloQBbo3/7QDhcpeLFcm48Z1bmWWshTQTgg6Zy8MeJ8v0BtkJDFCyDaiYWnJM NwfBnHcqZy4BUc7PviBH/QYzZQHulKpdwWqgXOuy92hJONj1Z97cJ66/0cdG0D774M6r8OAyEVs gvqRimRKK4IW42qvrbhFOlUvalO0hQuOtWAA/e8yQyb1z5IH5yv/TcwRtSWdwaiSp07QXDoB7d4 8ehmjztpyP/kNK5uyNUgRM0ZocRQ1iiUCshifYCcd1wB9pQI7iNokmz87TgI93oRuqFpwpYQSK+ zAGGRMe43ujsMXmiExQAUHq8cYx X-Received: by 2002:a0c:fde3:0:b0:8ce:ca78:409c with SMTP id 6a1803df08f44-8cee5fe4e78mr277619976d6.10.1781091253735; Wed, 10 Jun 2026 04:34:13 -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-8cecd26e9e3sm225660056d6.46.2026.06.10.04.34.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 04:34:13 -0700 (PDT) Date: Wed, 10 Jun 2026 07:34:11 -0400 From: Gregory Price To: Farhad Alemi Cc: Andrew Morton , David Hildenbrand , Farhad Alemi , Yury Norov , Joshua Hahn , Zi Yan , Matthew Brost , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , Waiman Long , Rasmus Villemoes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Message-ID: References: <25c4bc47-b65d-4c04-8a8f-18eef2b5566a@kernel.org> 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: On Tue, Jun 09, 2026 at 07:57:41PM -0400, Farhad Alemi wrote: > cpuset_update_tasks_nodemask() rebinds a task's own mempolicy to the > cpuset's effective, online mems (newmems, from guarantee_online_mems()), > but rebinds that task's VMA mempolicies to the *configured* mask instead: > > cpuset_change_task_nodemask(task, &newmems); > ... > mpol_rebind_mm(mm, &cs->mems_allowed); > > On the default (v2) hierarchy a cpuset that has never had cpuset.mems > written keeps mems_allowed empty while effective_mems is inherited > non-empty from the parent, and tasks may be attached to it (the > empty-mems attach check is v1-only). A subsequent rebind -- e.g. from a > CPU hotplug event walking the cpuset -- then calls mpol_rebind_mm() with > an empty mask. For a VMA policy created with MPOL_F_RELATIVE_NODES this > reaches mpol_relative_nodemask() -> > nodes_fold(..., nodes_weight(cs->mems_allowed) == 0) -> bitmap_fold(), > whose set_bit(oldbit % sz, dst) divides by zero: > > Oops: divide error: 0000 [#1] SMP KASAN NOPTI > RIP: 0010:bitmap_fold+0x5e/0xb0 > mpol_rebind_nodemask > mpol_rebind_mm > cpuset_update_tasks_nodemask > cpuset_handle_hotplug > sched_cpu_deactivate > cpuhp_thread_fun > > cs->mems_allowed is the only nodemask in this function that is not the > effective set: the task-policy rebind, the page-migration target and > cs->old_mems_allowed all use newmems. The sibling cpuset_attach() path > already rebinds VMA policies against the effective mems > (cpuset_attach_nodemask_to = cs->effective_mems) and explicitly notes > that mems_allowed can be empty under hotplug. Rebind the VMA policies to > newmems too: it is guaranteed non-empty by guarantee_online_mems(), which > fixes the divide-by-zero, and it makes the VMA policies consistent with > the task policy and with the nodes the task is actually allowed to use. > I think you can make this a bit more concise: Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/oneline echo 1 > /sys/devices/system/cpu/cpu1/oneline 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use mems_effective - the value returned by guarantee_online_mems() - instead, which is guaranteed to have a non-empty nodemask.. Maybe add a link to your reproducer and the original [BUG] Link: https://lore.kernel.org/linux-mm/CA+0ovCgxbZkXa+OU8w3s84R3KNPNxxRfmsNR-udh+afQBbGNmw@mail.gmail.com/ Link: https://lore.kernel.org/all/CA+0ovCiEz6SP_sn3kN4Tb+_oC=eHMXy_Ffj=usV3wREdQrUtww@mail.gmail.com/ Does this need a Closes tag? > Fixes: ae1c802382f7 ("cpuset: apply cs->effective_{cpus,mems}") > Suggested-by: Gregory Price > Signed-off-by: Farhad Alemi > Cc: stable@vger.kernel.org > --- > kernel/cgroup/cpuset.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > --- a/kernel/cgroup/cpuset.c > +++ b/kernel/cgroup/cpuset.c > @@ -2649,7 +2649,7 @@ void cpuset_update_tasks_nodemask(struct cpuset *cs) > > migrate = is_memory_migrate(cs); > > - mpol_rebind_mm(mm, &cs->mems_allowed); > + mpol_rebind_mm(mm, &newmems); > if (migrate) > cpuset_migrate_mm(mm, &cs->old_mems_allowed, &newmems); > else > -- > 2.43.0