Re: [PATCH] reject taskset for kernel threads

[Andrew Morton]

On Wed, 21 Mar 2007 21:53:53 +0100
Olaf Hering <olaf@xxxxxxxxx> wrote:

> 
> Do not allow taskset for kernel threads.
> These commands will cause oopses due to stack corruption:
> 
> ls /proc/*/task | grep -v ^/ | xargs echo | xargs -n1 taskset -pc 2-9
> taskset -pc 1 $$
> taskset -pc 0 $((pidof john))

Why does the kernel oops?

> Possible fix in userland:
> 
> for i in ` ls /proc/*/task | grep -v ^/ `
> do
> 	e=/proc/*/task/$i/exe
> 	if test -e $e
> 	then
> 		taskset -pc 2-9	$i
> 	fi
> done
> 
> 
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
> 
> ---
>  kernel/sched.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux-2.6.20/kernel/sched.c
> ===================================================================
> --- linux-2.6.20.orig/kernel/sched.c
> +++ linux-2.6.20/kernel/sched.c
> @@ -4310,6 +4310,8 @@ long sched_setaffinity(pid_t pid, cpumas
>  	read_unlock(&tasklist_lock);
>  
>  	retval = -EPERM;
> +	if (!p->mm)
> +		goto out_unlock;
>  	if ((current->euid != p->euid) && (current->euid != p->uid) &&
>  			!capable(CAP_SYS_NICE))
>  		goto out_unlock;


Maybe.  There are some kernel threads for which we definitely don't want
the affinity altered (ksoftirqd, probably keventd..).  But otoh there might
be legitimate reasons to alter, say, pdflush's or kjournald's affinity, and
that should be a safe thing to do.

Perhaps a suitable compromise would be to disallow affinity-setting on
non-singlethreaded kernel threads.  But of course, we don't want that to
oops.

-
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/