lkml.org 
[lkml]   [2006]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] exec: Only allow a threaded init to exec from the thread_group_leader
ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> The weird things we do when we exec from a thread group are just ugly.
> Those ugly things do not handle the case of init and I suspect
> extending that code to properly support a threaded init would be just
> hideous, and impossible to maintain.
>
> So just in case someone ever threads init return an error for the
> unimplemented case.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
>
> ---
>
> fs/exec.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> 408dad0f2b7067b23929866150e73b2b2f12d662
> diff --git a/fs/exec.c b/fs/exec.c
> index 055378d..c9d8e31 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -600,6 +600,12 @@ static int de_thread(struct task_struct
> if (thread_group_empty(current))
> goto no_thread_group;
>
> + /* A threaded init must exec from it's primary thread.
> + * As the init task (i.e. child_reaper) may not exit.
> + */
> + if (!thread_group_leader(current) && (current->tgid == 1))
> + return -EINVAL;
> +
> /*
> * Kill all other threads in the thread group.
> * We must hold tasklist_lock to call zap_other_threads.

hmm, this just looks like overhead. If sometime someone _does_ try to
thread init, what will happen to them? If it's something nice and nasty,
they'll just whine at us and stop doing that. Same net effect, no runtime
cost.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-29 09:38    [W:4.378 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site