Re: [PATCH] sched_getaffinity() fails with -EINVAL

[KOSAKI Motohiro <kosaki dot motohiro at jp dot fujitsu dot com>]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/19/2010 07:43 AM, Sharyathi Nagesh wrote:
> > Kosaki I am not completely convinced how we can suggest changes to
> > kernel code. Meanwhile changing the interfaces to  *_S macros looks more
> > appropriate
> 
> The kernel, for the slim probability that somebody uses hotplug CPUs and
> increases the number of CPUs, always checks the maximum number of
> configured CPUs fits in the cpu set.
> 
> An alternative would be to always just test the number of configured
> CPUs at the time of the call.  This is backward compatible and wouldn't
> hurt most people even with a maximum of 2048 CPUs.
> 
> Only if the bitset is really too small would we get errors.
>
> The only problem is what to do if the number of online CPUs increases.I
> think defaulting to off is just as valid a solution as accepting info in
> setaffinity calls for CPUs which are unknown at the time of the call.

I think it is easy rather than you expect. because the kernel is tracking
cpu-hotplug aware cpumask. I mean the number maximum cpus are two type. 

 (1). the maximum cpus in the distro.
	it independent on the machine.
	it is calculated at kernel built.
 (2). the maximum cpus in the system.
	it depend on the machine. 
	it is calculated at boot time.

now the kerenel use (1) for argument sanity check. but instead it should use (2).
Without SGI monstor machine, (2) is less than 1024. IOW, typical user don't fit
cpu_set_t limit.

I'll post a kernel patch to lkml soon.

thanks.