[lkml]   [2004]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Fix argument checking in sched_setaffinity

On Sat, 4 Sep 2004, Paul Jackson wrote:
> My understanding of "asking for it" requires at present a user code
> loop, to probe for the size that works.

Yeah, or just make a frigging big area, and asking the kernel for it ;)

Something like

/* We just assume that 8k CPU's aren't going to happen */
#define MAX_CPUMASK_BYTES (1024)

void *cpumask = malloc(MAX_CPUMASK_BYTES);
int real_size = sched_getaffinity(0, cpumask, MAX_CPUMASK_BYTES);

and no loop needed.

> But my user code already does
> that, and the first thing for which I audit any changes to this kernel
> code is not breaking my sizing loop code in user space.

I don't think you can reasonably use the "setaffinity()" call for sizing,
since that historically just refused to use anything but the exact size.
Sure, you could loop over every byte value known to man, but it's just a
lot easier to do the "getaffinity" thing - if it fails, you can double the
size of your buffer and try again. O(log(n)) rather than O(n) ;)

(And the "just start high enough" approach means that you can basically
make it O(1) if you don't care about the theoretical possibility of a
8k-CPU monster machine).

> I'd mildly prefer adding a kernel/user API for explicitly providing the
> two values:
> sizeof(cpumask_t)
> sizeof(nodemask_t)
> This might help reduce the unending confusions in the user and library
> code sitting on top of us.

I don't know how to sanely expose the damn things. Maybe in the vsyscall
page or something. Adding YAEAE (yet another ELF aux entry) could be done,
of course.

> We could two phase this:
> 1) add an obvious way to size these masks, and then
> 2) six months later, require sizes to match in all these calls.

Well, historically we _have_ required sizes to match. You can pass in
larger sizes to the "get" functions (and they'll tell you how much you
got), but the "set" functions required the user to know exactly what the
size was. Which is easy, see above.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [W:0.128 / U:0.268 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site