From: Gregory Price <gourry@gourry.net>
To: Liu Jing <liujing@cmss.chinamobile.com>
Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com,
matthew.brost@intel.com, joshua.hahnjy@gmail.com,
rakie.kim@sk.com, byungchul@sk.com,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mempolicy: fix div-by-zero in alloc_pages_bulk_interleave
Date: Wed, 2 Sep 2026 10:04:57 -0400 [thread overview]
Message-ID: <apgrrQM5cFWRA4HR@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20260902090245.16411-1-liujing@cmss.chinamobile.com>
On Wed, Sep 02, 2026 at 05:02:45PM +0800, Liu Jing wrote:
> In alloc_pages_bulk_interleave(), nodes_weight(pol->nodes) may return
> 0 if all nodes in the policy mask have been offlined at runtime. The
> subsequent division "nr_pages / nodes" triggers a divide-by-zero
> panic.
>
now i'm positive this is LLM produced without understanding the
component.
A policy cannot have an empty nodemask, it can either
1) have no nodemask (default policy), or
2) be perceived as empty during a torn-read during a policy remap event
If you are running LLMs to search for surface level bugs and try to
hot-fix them without taking time to understand the underlying component,
please at least:
1) tell us that
2) generate reproducers
these "quick fixes" based on surface level observations are going to hide
real bugs and just degrade the overall state of the system.
> Add a zero check returning 0 (no pages allocated) when the nodemask
> is empty, consistent with the guard in
> alloc_pages_bulk_weighted_interleave().
>
> Signed-off-by: Liu Jing <liujing@cmss.chinamobile.com>
> ---
> mm/mempolicy.c | 3 +++
> 1 file changed, 3 insertion(+), 0 deletion(-)
>
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -2600,6 +2600,9 @@
> unsigned long total_allocated = 0;
>
> nodes = nodes_weight(pol->nodes);
> + if (!nodes)
> + return 0;
> +
> nr_pages_per_node = nr_pages / nodes;
> delta = nr_pages - nodes * nr_pages_per_node;
>
>
> --
> 2.43.0
>
>
prev parent reply other threads:[~2026-09-02 14:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 9:02 [PATCH] mempolicy: fix div-by-zero in alloc_pages_bulk_interleave Liu Jing
2026-09-02 14:04 ` Gregory Price [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=apgrrQM5cFWRA4HR@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liujing@cmss.chinamobile.com \
--cc=matthew.brost@intel.com \
--cc=rakie.kim@sk.com \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.