On Thu, 12 Feb 2009 14:08:09 -0800 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote: > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > > > The problem with set_cpus_allowed() is that some other > > suitably-privileged userspace process can come in from the side and > > modify your cpus_allowed at any time. > > According to the comments the only reason we care is so that > we get the appropriate NUMA affinity by default. I don't > think it would be fatal if userspace messed around and we > had a wrong value. Right. In this particular case, if you are fantastically unlucky and hit the race window, all that will happen is that one particular device will run a bit more slowly. But at other codesites, the effects of a racing cpus_allowed rewrite can be fatal. > Does work_on_cpu prevent that? Yup. I think. Nope. I don't think there's actually anything which would prevent a sufficiently stupid/malicious/unlucky administrator from moving the work_on_cpu thread onto the wrong CPU at the wrong time. hrm. Another reason to use smp_call_function_single(). -- To unsubscribe from this list: send the line "unsubscribe mm-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
