[email protected] (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 <[email protected]>
>
>
> ---
>
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
