Re: [PATCH] mm/mempolicy: prevent the risk of division by 0

["Huang, Ying" <ying.huang@linux.alibaba.com>]

Joshua Hahn <joshua.hahnjy@gmail.com> writes:

> On Sun,  7 Sep 2025 09:08:29 -0700 Chelsy Ratnawat <chelsyratnawat2001@gmail.com> wrote:
>
>> If no bits are set in the policy's node mask, then nodes will be 0.
>> This patch adds a check if nodes == 0 before dividing.
>
> Hello Chelsy,
>
> Thank you for the patch! I will start off by saying that it probably does not
> hurt to add a check like this. With that said, I think it's best if we clarify:
>
> (1) Have we seen this happen before?
> (2) Should we add a Fixes tag?
> (3) Do we expect to hit the nodes == 0 case, or is this just to be safe?
> (4) If so, should we do more than just return 0 (i.e. WARN_ON?)
>
> From what I can tell, I think it should not be possible for the policy to be
> interleave, and the nodes to be null. If we look at mpol_new, there is an
> explicit call to nodes_empty that checks if the nodes are empty, and returns
> an error if that is the case (of course, excluding MPOL_DEFAULT, which actually
> throws an error if the nodes are not empty).
>
> After all, it doesn't really make semantic sense to allow interleaving across
> 0 nodes ; -)
>
> But as always, it is very possible that I am missing something that you are
> seeing : -) Please feel free to correct me if you believe that is the case.
>
> With all of this said, I do agree that it's a bit scary to do a div0, even if
> I am confident that the value shouldn't be zero. I don't have any strong
> feelings about adding redundant checks, so I will let other mempolicy reviewers
> chime in with thier opinions. One thing I do feel strongly though, is that if
> we are to move forward in the patch, some explicit clarification that we
> have/have not seen it happen before, and a WARN_ON would make sense. 

IIUC, the patch is to catch the bug during kernel development.  And, if
an exception can be generated for dividing by 0, it can be used to catch
the bug already.  If so, IMHO, the patch appears unnecessary.

[snip]

---
Best Regards,
Huang, Ying