[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170405162458.GF14536@redhat.com>
Date: Wed, 5 Apr 2017 18:24:59 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Aleksa Sarai <asarai@...e.com>,
Andy Lutomirski <luto@...capital.net>,
Attila Fazekas <afazekas@...hat.com>,
Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>,
Michal Hocko <mhocko@...nel.org>,
Ulrich Obergfell <uobergfe@...hat.com>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [RFC][PATCH v2 3/5] clone: Disallown CLONE_THREAD with a
shared sighand_struct
On 04/02, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1515,6 +1515,13 @@ static __latent_entropy struct task_struct *copy_process(
> if ((clone_flags & CLONE_THREAD) && !(clone_flags & CLONE_SIGHAND))
> return ERR_PTR(-EINVAL);
>
> + /* Disallow CLONE_THREAD with a shared SIGHAND structure. No
> + * one cares
Well, can't resists... I won't argue, but we can't know if no one cares
or not. I agree that most probably this won't break something, but who
knows... I am always scared when we add the incompatible changes.
> and supporting it leads to unnecessarily complex
> + * code.
> + */
> + if ((clone_flags & CLONE_THREAD) && (atomic_read(¤t->sighand->count) > 1))
> + return ERR_PTR(-EINVAL);
Perhaps the comment should explain why we do this and say that
sighand-unsharing in de_thread() depends on this.
Oleg.
Powered by blists - more mailing lists