Re: [Lse-tech] Re: [PATCH] cpusets+hotplug+preepmt broken

[Srivatsa Vaddagiri <vatsa@in.ibm.com>]

On Fri, May 13, 2005 at 07:58:51PM -0700, Paul Jackson wrote:
> Why just in sched_setaffinity()?  What about the other 60+ calls to
> set_cpus_allowed().  

Most of the 60+ calls seem to be in arch-specific code. We don't bother
about arch'es which dont support CPU Hotplug. AFAIK, only ppc64, ia64
and s390 support it (as of today that is :)

> Shouldn't most of those calls be checking that the
> passed in cpus are online (holding lock_cpu_hotplug while doing all
> this)?  Either that, or at least handling the error from
> set_cpus_allowed() if the requested cpus end up not being online?  

Yes, if these calls can run on CPU Hotplug supported platforms.

Apart from being buggy on this count (that they don't lock_cpu_hotplug
and/or don't check return value), they will also be buggy
if any code uses set_cpus_allowed against a user-space task to
migrate to a different CPU. Something like:

	old_allowed = tsk->cpus_allowed;
	set_cpus_allowed(tsk, new_mask);
	/* Do something */
	/* Restore mask */
	set_cpus_allowed(tsk, old_allowed);

This is buggy because it can race with sched_setaffinity against the same task.

Having said that, the major remaining offenders (in arch-independent code) seem
to be cpufreq, sn_hwperf, acpi, perfctr/virtual.c, attach_task :), 
net/core/pktgen.c (needs to be converted over to kthread_start/stop interface).

Now how much of this actually runs on the CPU Hotplug supported platforms?
Don't know ..But it is neverthless good to fix few of these ..

In fact, some of these and other set_cpus_allowed woes were discussed here:

http://sourceforge.net/mailarchive/forum.php?thread_id=3582487&forum_id=35582



-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017