From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 3F137367F36 for ; Fri, 29 May 2026 15:26:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780068383; cv=none; b=qL5W1EYRsnfiYge4SIF0+j2+/GKBe3Q8k8LbWBjZFZyNC7cuAkJAwyslt+VGJXLWrBBbC4fyiW2VbXcxEoamuOc+xjoxiKYPDPtETJyO/6qkyO66o5fYw82x94j3a/lsdVwgW/f3LFHU4h+OwAVPcWV+XTUATHakCGTi9KwDWJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780068383; c=relaxed/simple; bh=fUAVSg4QOZYnfadLomH8mFKt48yRGhCh20ru3bdN+Ww=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c2kO/P4pqMJ7KbkSSPKlVLOhOEfJnCn+cKn98CPBOxytGl9lAnrtMqydNb/V2sPwDcZcxM4CtfUR2mUrk7RgD52xFLKHFyFJGIHq9j7BucnE+8vN3XEOUqthzDM8mTHAv/zF6PiHLzjMgUmZoobf8nLI56+LzK/TbwGerCqcrLw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=YLWHn8fo; arc=none smtp.client-ip=209.85.167.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YLWHn8fo" Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-4856128f670so5354274b6e.0 for ; Fri, 29 May 2026 08:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780068381; x=1780673181; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hXXCbhIHtRNsHen8pCYQ+YRxwoUgedEKjJY0J2w8T+s=; b=YLWHn8fo8uGidYq/Tb9nb00wlR0HlF5H5S/CACTxwNgE8Px4B0COQhsqME/hYCQgsd nkU9iikiVwCY64i5kp6a2ht5dlh82isWiZu8jrMrabqzSoPZzCN0MNUptavWbTTp+/Tk HpLhCzV0Uuu2JcffIFLWG2lJZzrkbYa4a6VV+elu2RqsrSwjNDPJ9+DytFFiHuy8DFaF dwhrnLc9oUERsd/BRS4C4rds9GKBTpYTVd/LYhVxsZWksh4ZpwJfo72wMHWL3K7YNaTO Vx8Ebjq07R58E27lYZXL2s0MM1nVMXj5h/DhTeOAgnxqCQMvFaa1oGEF3imJL5S3fi97 uA4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780068381; x=1780673181; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hXXCbhIHtRNsHen8pCYQ+YRxwoUgedEKjJY0J2w8T+s=; b=aZ2az5Azs3dhwFXYC3NmlQzlfBH8y5b02EzUJvdZtI1jUf50Pp1PFsCE5sQvyy5wCS PtlRtPBXMHqtR42nnzfO92ob2SevMjzzJiW6/g+IIz5wipQvabJPW5PY3eI2+cLT9J24 lOn9S7PqsTdpkKOcuvINH4Gt81wPRohDdl+oosNy0qqM4HCd29dzqVfUrrfzyvwM2Pui Eictfo15RkgwoMkhLGq8zCzRVoUupvR33/cSIfxnzvS4Xtv+gZnqSWuPElUcQln3aSlB MUQmJMI72ydfYlWKb0tybJwhB1/qyrBTiioVy6cU/FvcnvGz7OcN34k3zIWGa87m6MGy uo/g== X-Forwarded-Encrypted: i=1; AFNElJ8kXLvVawFgVUrZ/IS36BQI3IJ7ecev9fBEB0czHSCbdKnjbvD+gbctw1tGDFAuBp6ix0KcY7+PjF93Kk8=@vger.kernel.org X-Gm-Message-State: AOJu0YzEeCBVn5NBGMr1zEk82x5qif7RPOQgm6Rl61BTclngQXJx33vM VSavby2SCk59Umtr91UDuay70NNiHMFFqY1GdCwI1Z9Qy5K0pdtOZSqF X-Gm-Gg: Acq92OHIL5PUasVAuuBxh0GXzP0xT9zQJhB2ULCaL9JdiG05kFNw9LIWEntXomyINQa HxxQlJJ1KzCHnxPGehfiHlooEcPvYFplPdkiXNUbSq2Bniikbv8/UQpExplB0yyDCsYJG3n+sXe i9mmowvsMSgmo8ERurg3o4P6aSWZwQO1PNLK08Fu/OqHlLIJsIZov47AjIuWBx3ucYxCk6tmTWu o8S0bi3WNdLJWqXE/vUy+cbE0mBy/Xlxw5LYPuFP6TjghL11ukJUw1mq2OISub91kkYGVvCfFvc rKrv31s+cOxFEMm/4mUKIvqWiS4P2zEliV98ABZ21iYe7p2rejYgGVd/hZEl9RXlBHQrgIXAMRn 0YrftZe4jxTTRJrJ1FLPQbcugt2PTs/rBlbbprEO1Q4eESocsebmWT2PGTxDq9+13OzeOJ2QeuT ZsXeg7d3H9GzNTgeSJc6Tydsaun3mN2u6sI4yMreEZPeonulMaIgUK8fYqsW8uzTI= X-Received: by 2002:a05:6808:170b:b0:467:254:b90 with SMTP id 5614622812f47-485e698fcb0mr1813824b6e.10.1780068381169; Fri, 29 May 2026 08:26:21 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:b::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-485edc5fa67sm792027b6e.6.2026.05.29.08.26.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 08:26:19 -0700 (PDT) From: Joshua Hahn To: Andrew Morton Cc: Yury Norov , David Hildenbrand , Zi Yan , Matthew Brost , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Farhad Alemi , Waiman Long , Rasmus Villemoes , cgroups@vger.kernel.org Subject: Re: [PATCH] mm: don't allow empty relative nodemask in mpol_relative_nodemask() Date: Fri, 29 May 2026 08:26:15 -0700 Message-ID: <20260529152616.2308736-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260528124133.c88c27b11a8ea0ef05e494f7@linux-foundation.org> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, 28 May 2026 12:41:33 -0700 Andrew Morton wrote: > On Thu, 28 May 2026 15:03:37 -0400 Yury Norov wrote: > > > Reassigning nodes relative an empty user-provided nodemask is useless, > > and triggers divide-by-zero in the function. > > > > Reported-by: Farhad Alemi > > Link: https://lore.kernel.org/all/CA+0ovCgxbZkXa+OU8w3s84R3KNPNxxRfmsNR-udh+afQBbGNmw@mail.gmail.com/ > > Thanks both. > > It looks like this is very old code, so we'll be wanting a cc:stable in > this. > > > --- a/mm/mempolicy.c > > +++ b/mm/mempolicy.c > > @@ -370,8 +370,13 @@ static inline int mpol_store_user_nodemask(const struct mempolicy *pol) > > static void mpol_relative_nodemask(nodemask_t *ret, const nodemask_t *orig, > > const nodemask_t *rel) > > { > > + unsigned int w = nodes_weight(*rel); > > nodemask_t tmp; > > - nodes_fold(tmp, *orig, nodes_weight(*rel)); > > + > > + if (w == 0) > > + return -EINVAL; > > + > > + nodes_fold(tmp, *orig, w); > > nodes_onto(*ret, tmp, *rel); > > } > > I suspect we should address this at the mpol level - it should never > have got that far. Hopefully the mempolicy maintainers can have a > think. Hello Andrew, hello Yury, I agree with Andrew here. mpol_relative_nodemask is called from two places, the first being mpol_rebind_nodemask which is the calling function seen in the bug report as well. The other place is mpol_set_nodemask, which has a helpful comment that notes: "mpol_set_nodemask is called after mpol_new() [...snip...] mpol_new() has already validated the nodes parameter with respect to the policy mode and flags". So it seems like we are missing the big if-else if-else if block from mpol_new in other places that should in fact have it, like mpol_rebind_nodemask. The approach proposed here of just checking whether the node weight is 0 won't work for a few cases, namely for MPOL_DEFAULT and MPOL_PREFERRED where empty nodemasks are actually allowed. So what should really be done here is to do the full policy-nodemask checking section in mpol_new and call that from mpol_set_nodemask as well. Thank you for taking a shot at fixing the bug report, please let me know what you think! Have a great day : -) Joshua