Re: [RFC] Restrict kernel spawning of threads to a specified set ofcpus.

[Frederic Weisbecker]

On Thu, Sep 12, 2013 at 03:42:21PM +0000, Christoph Lameter wrote:
> Let me just say that the user space approach does not work because the
> kernel sets the cpumask to all and then spawns a thread f.e. for
> usermodehelper.
> 
> This mean we would have to run a daemon that keeps scanning for errand
> threads and then move them. But at that point the damage would already
> have been done. Short term threads would never be caught.
> 
> So I think the kernel based approach is unavoidable.
> 
> Look at this in kernel/kmod.c:
> 
> static int ____call_usermodehelper(void *data)
> {
>         struct subprocess_info *sub_info = data;
>         struct cred *new;
>         int retval;
> 
>         spin_lock_irq(&current->sighand->siglock);
>         flush_signal_handlers(current, 1);
>         spin_unlock_irq(&current->sighand->siglock);
> 
>         /* We can run anywhere, unlike our parent keventd(). */
>         set_cpus_allowed_ptr(current, cpu_all_mask);
> 
> 
> !!!!! No chance to catch this from user space.
> 
> 
> 
> 	....
> 
>         retval = do_execve(sub_info->path,
>                        (const char __user *const __user *)sub_info->argv,
>                            (const char __user *const __user *)sub_info->envp);
>         if (!retval)
> 
> 
> 	....
> 

Yeah, setting the threads affinity is racy from userspace in any case. By the time
one scan /proc for tasks, some others can be forked concurrently.

So yeah it's a problem in theory. Now in practice, I have yet to be convinced because
this should be solved after a few iterations in /proc in most cases.

Now the issue doesn't only concern kthreads but all tasks in the system.
If we really want to solve that race, then may be we can think of a kernel_parameter
that sets the initial affinity of init and then lets get it naturally inherited
through the whole tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/