Re: + work_on_cpu-rewrite-it-to-create-a-kernel-thread-on-demand.patch added to -mm tree

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 12 Feb 2009 14:08:09 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@linux-foundation.org> 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().