All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: <rcampbell@nvidia.com>
Cc: <linux-mm@kvack.org>, Waiman Long <longman@redhat.com>
Subject: Re: [PATCH] numa: Change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES
Date: Mon, 11 Feb 2019 11:27:59 -0800	[thread overview]
Message-ID: <20190211112759.a7441b3486ea0b26dec40786@linux-foundation.org> (raw)
In-Reply-To: <20190211180245.22295-1-rcampbell@nvidia.com>

On Mon, 11 Feb 2019 10:02:45 -0800 <rcampbell@nvidia.com> wrote:

> From: Ralph Campbell <rcampbell@nvidia.com>
> 
> The system call, get_mempolicy() [1], passes an unsigned long *nodemask
> pointer and an unsigned long maxnode argument which specifies the
> length of the user's nodemask array in bits (which is rounded up).
> The manual page says that if the maxnode value is too small,
> get_mempolicy will return EINVAL but there is no system call to return
> this minimum value. To determine this value, some programs search
> /proc/<pid>/status for a line starting with "Mems_allowed:" and use
> the number of digits in the mask to determine the minimum value.
> A recent change to the way this line is formatted [2] causes these
> programs to compute a value less than MAX_NUMNODES so get_mempolicy()
> returns EINVAL.
> 
> Change get_mempolicy(), the older compat version of get_mempolicy(), and
> the copy_nodes_to_user() function to use nr_node_ids instead of
> MAX_NUMNODES, thus preserving the defacto method of computing the
> minimum size for the nodemask array and the maxnode argument.
> 
> [1] http://man7.org/linux/man-pages/man2/get_mempolicy.2.html
> [2] https://lore.kernel.org/lkml/1545405631-6808-1-git-send-email-longman@redhat.com
> 

Ugh, what a mess.

For a start, that's a crazy interface.  I wish that had been brought to
our attention so we could have provided a sane way for userspace to
determine MAX_NUMNODES.

Secondly, 4fb8e5b89bcbbb ("include/linux/nodemask.h: use nr_node_ids
(not MAX_NUMNODES) in __nodemask_pr_numnodes()") introduced a
regession.  The proposed get_mempolicy() change appears to be a good
one, but is a strange way of addressing the regression.  I suppose it's
acceptable, as long as this change is backported into kernels which
have 4fb8e5b89bcbbb.


  reply	other threads:[~2019-02-11 19:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 18:02 [PATCH] numa: Change get_mempolicy() to use nr_node_ids instead of MAX_NUMNODES rcampbell
2019-02-11 19:27 ` Andrew Morton [this message]
2019-02-27 18:38   ` Vlastimil Babka
2019-02-28 19:11     ` Andrew Morton
2019-02-28 20:43       ` Vlastimil Babka

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=20190211112759.a7441b3486ea0b26dec40786@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=longman@redhat.com \
    --cc=rcampbell@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.