From: bugzilla-daemon@kernel.org
To: linux-man@vger.kernel.org
Subject: [Bug 217253] New: mbind, set_mempolicy, migrate_pages: maxnode description is off-by-one
Date: Mon, 27 Mar 2023 14:05:42 +0000 [thread overview]
Message-ID: <bug-217253-11311@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=217253
Bug ID: 217253
Summary: mbind, set_mempolicy, migrate_pages: maxnode
description is off-by-one
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: man-pages
Assignee: documentation_man-pages@kernel-bugs.osdl.org
Reporter: tonyb@cybernetics.com
Regression: No
linux/mm/mempolicy.c::get_nodes() does "--maxnode" at the beginning, so:
maxnode == 0 is invalid (-EINVAL).
maxnode == 1 specifies the empty set of nodes (the man pages currently say to
use maxnode == 0).
maxnode == 2 indicates one valid bit in nodemask.
maxnode == 3 indicates two valid bits in nodemask.
etc.
Incorrect section from mbind manpage:
"nodemask points to a bit mask of nodes containing up to maxnode bits. The bit
mask size is rounded to the next multiple of sizeof(unsigned long), but the
kernel will use bits only up to maxnode. A NULL value of nodemask or a maxnode
value of zero specifies the empty set of nodes. If the value of maxnode is
zero, the nodemask argument is ignored."
I am not sure if this was an intentional design choice or a bug that got
enshrined in the userspace API, but userspace programs "in the know" seem to
rely on this now:
https://gitlab.com/qemu-project/qemu/-/blob/60ca584b8af0de525656f959991a440f8c191f12/backends/hostmem.c#L369
Also, the commit message for linux commit c6018b4b2549 ("mm/mempolicy: add
set_mempolicy_home_node syscall") shows using "new_nodes->size + 1", so this
API bug/choice seems to be known within the kernel community.
Here is a related bugzilla entry that treats the problem as a kernel bug rather
than a documentation issue:
https://bugzilla.kernel.org/show_bug.cgi?id=201433
But since "fixing" the bug (assuming that it was unintentional) might break
existing userspace programs that work around the bug, I suggest fixing the
documentation instead. But that is just my opinion as a user who just ran into
the bug and did some investigating; best to check with the kernel maintainers
for their opinion.
Related:
linux commit 050c17f239fd ("numa: change get_mempolicy() to use nr_node_ids
instead of MAX_NUMNODES") commit message talks about calculating maxnode for
get_mempolicy().
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2023-03-27 14:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 14:05 bugzilla-daemon [this message]
2023-05-19 11:46 ` [Bug 217253] mbind, set_mempolicy, migrate_pages: maxnode description is off-by-one bugzilla-daemon
2023-05-19 11:51 ` bugzilla-daemon
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=bug-217253-11311@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-man@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox