[RFC] get_mempolicy(2) behaviour

[RFC] get_mempolicy(2) behaviour

[Al Viro]

	Behaviour of get_mempolicy(2) with nmask != NULL is
bloody weird.  It doesn't match the manpage (and never had) _and_
it doesn't match the behaviour of compat variant.

	For native (both 32bit and 64bit host) there are two cases
when it fails with -EINVAL - namely, maxnode being less than the
actual number of nodes and maxnode being greater than PAGE_SIZE * 8 + 1.
Otherwise, it stores ((maxnode - 1) rounded up to 64) bits, with
the actual bitmap in the beginning and zeroes padding it.  So far,
so good, except that
	* having maxnode = 64k + 1 equal to actual number of nodes
will quietly lose the last bit of bitmap.
	* manpage says "maxnode specifies the number of node IDs
that can be stored into nodemask --- that is, the maximum node ID plus one.
The value specified by maxnode is always rounded to a multiple of
sizeof(unsigned long)*8".  It's actually rounded to a multiple
of 64, whether we are on 32bit or on a 64bit host.

	Compat is different.  While the first case where native would've
failed with -EINVAL (maxnode less than the actual number of nodes) still
gives the same error, the second case (maxnode being huge) does not fail
at all.

	Worse, the amount we actually store is
((maxnode - 1) rounded up to 8) bits if maxnode greater than the actual
number of nodes *and* ((maxnode - 1) rounded up to 32) bits if
maxnode is equal to the actual number of bits.  And the case of quietly
lost bit is also slightly different from the native one - it's still
"maxnode is equal to the actual number of nodes", but here it needs
to be 1 + multiple of 32.

	At the very least, compat behaviour ought to match what the native
syscall wouldn't done on 32bit host.  And having the manpage match
the reality would be nice as well.  Should we do something about the
cases when the data gets quietly lost?

	Comments?

Re: [RFC] get_mempolicy(2) behaviour

[Andi Kleen]

Hi Al,

Yes it's quite a mess, but it's hard to change now.

> 	At the very least, compat behaviour ought to match what the native
> syscall wouldn't done on 32bit host. 

I suspect 32bit NUMA usage isn't that wide spread, but yes would make
sense.

> And having the manpage match
> the reality would be nice as well.  

Yep.

> Should we do something about the
> cases when the data gets quietly lost?

In theory it could break something, but I suppose the case is unlikely
enough that noone relies on it.

-Andi