Re: [PATCH] mm/nodemask: Correctly describe nodemask operation return types
From: Joshua Hahn
Date: Mon Jun 01 2026 - 10:42:35 EST
> On Fri, 29 May 2026 13:27:54 -0700 Joshua Hahn <joshua.hahnjy@xxxxxxxxx> wrote:
>
> > Commit 0dfe54071d7c8 ("nodemask: Fix return values to be unsigned")
> > changed a number of nodemask operations that used to return int
> > to returning a bool instead. However, it did not update the comment
> > block that described these functions, leaving the documentation
> > incorrect.
> >
> > Fix the comment block to accurately describe the functions.
> > Also fix a typo (unsigend --> unsigned), and fix a callsite in
> > mempolicy.c that did not get updated during the conversion.
>
> Nice catch, thank you fixing this!
>
> >
> > No functional changes intended; changes are purely cosmetic.
> >
> > Signed-off-by: Joshua Hahn <joshua.hahnjy@xxxxxxxxx>
>
> Reviewed-by: SeongJae Park <sj@xxxxxxxxxx>
Thank you, SJ!
> > * unsigned int first_node(mask) Number lowest set bit, or MAX_NUMNODES
> > - * unsigend int next_node(node, mask) Next node past 'node', or MAX_NUMNODES
> > + * unsigned int next_node(node, mask) Next node past 'node', or MAX_NUMNODES
> > * unsigned int next_node_in(node, mask) Next node past 'node', or wrap to first,
> > * or MAX_NUMNODES
> > * unsigned int first_unset_node(mask) First node not set in mask, or
>
> I feel like this comment block might be easy to be outdated in future. This
> comment block is introduced before the git era. I think this was the best and
> great way at that time. But now we have modern documentation tools like
> kernel-doc. I'm wondering if it makes sense to convert this comment block to
> kernel-doc comments in long term, after this patch is merged. If we sure these
> APIs are quite stable and expect no many changes in future, such conversion may
> not make sense, though.
I agree with this. I'm not entirely too sure if we expect too many changes
in this section, but I could always be surprised : -) I would say that even
in 2022 (when the nodemask function changes happened) not many people would
have expected changes to this otherwise stable set of functions.
So maybe the next changes to the function should also do the migration!
Thanks again, SJ! I hope you have a great day,
Joshua