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?
