linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Brent Casavant <bcasavan@sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] get_nodes mask miscalculation
Date: Tue, 10 Aug 2004 03:44:52 +0200	[thread overview]
Message-ID: <m31xifu5pn.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <2rr7U-5xT-11@gated-at.bofh.it> (Brent Casavant's message of "Tue, 10 Aug 2004 00:50:07 +0200")

Brent Casavant <bcasavan@sgi.com> writes:

The idea behind this is was to make it behave like select.
And select passes highest valid value + 1. In this case
valid value is not the highest bit number, but the length
of the bitmap.

For some reason nobody except me seems to get it though,
probably because the description in the manpages is a bit confusing:

get_mempolicy(2): 

"maxnode is the maximum bit number plus one that can be stored into
nodemask."

I suppose this should be better described. For changing it 
it is too late unfortunately because the libnuma binaries
are already out in the wild.

> It appears there is a nodemask miscalculation in the get_nodes()
> function in mm/mempolicy.c.  This bug has two effects:
>
> 1. It is impossible to specify a length 1 nodemask.

Sure. You pass 2.

> 2. It is impossible to specify a nodemask containing the last node.

you pass number of nodes + 1.

> The following patch against 2.6.8-rc3 has been confirmed to solve
> both problems.

Problem is that you'll break all existing libnuma binaries 
which pass NUMA_MAX_NODES + 1. In your scheme the kernel
will access one bit beyond the bitmap that got passed,
and depending on its random value you may get a failure or not.

BTW there is a minor problem in the code that there isn't a upper
limit. When you pass 0 it currently iterates through all your memory
until it hits an EFAULT, which can be a bit slow. But that's easy to
fix.

-Andi


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

       reply	other threads:[~2004-08-10  1:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2rr7U-5xT-11@gated-at.bofh.it>
2004-08-10  1:44 ` Andi Kleen [this message]
2004-08-10  5:25   ` Paul Jackson
2004-08-10 10:45     ` Andi Kleen
2004-08-17  3:43       ` Paul Jackson
2004-08-10 14:54   ` Brent Casavant
2004-08-10 15:34     ` Andi Kleen
2004-08-09 22:39 Brent Casavant

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=m31xifu5pn.fsf@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=bcasavan@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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