All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Adrian Reber <areber@redhat.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Pavel Emelianov <xemul@virtuozzo.com>,
	Jann Horn <jannh@google.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	linux-kernel@vger.kernel.org, Andrei Vagin <avagin@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Radostin Stoyanov <rstoyanov1@gmail.com>
Subject: Re: [PATCH v5 1/2] fork: extend clone3() to support CLONE_SET_TID
Date: Mon, 12 Aug 2019 18:37:10 +0200	[thread overview]
Message-ID: <20190812163710.GC31560@redhat.com> (raw)
In-Reply-To: <20190811203327.5385-1-areber@redhat.com>

On 08/11, Adrian Reber wrote:
>
>  include/linux/pid.h        |  2 +-
>  include/linux/sched/task.h |  1 +
>  include/uapi/linux/sched.h |  1 +
>  kernel/fork.c              | 22 ++++++++++++++++++++--
>  kernel/pid.c               | 36 +++++++++++++++++++++++++++++-------
>  5 files changed, 52 insertions(+), 10 deletions(-)

Looks good to me...

A couple of nits below, but I won't insist, feel free to ignore.

> +/*
> + * Different sizes of struct clone_args
> + */
> +#define CLONE3_ARGS_SIZE_V0 64

I don't really understand why do we want the "size < CLONE3_ARGS_SIZE_V0"
check in copy_clone_args_from_user(), but I won't argue.

> +/* V1 includes set_tid */
> +#define CLONE3_ARGS_SIZE_V1 72

unused?

> @@ -2031,7 +2038,13 @@ static __latent_entropy struct task_struct *copy_process(
>  	stackleak_task_init(p);
>  
>  	if (pid != &init_struct_pid) {
> -		pid = alloc_pid(p->nsproxy->pid_ns_for_children);
> +		if (args->set_tid && !ns_capable(
> +				p->nsproxy->pid_ns_for_children->user_ns,
> +				CAP_SYS_ADMIN)) {
> +			retval = -EPERM;
> +			goto bad_fork_cleanup_thread;
> +		}
> +		pid = alloc_pid(p->nsproxy->pid_ns_for_children, args->set_tid);

copy_process() is already huge and complex, why not move this check into
alloc_pid() ? Again, note that is accepts the same ->pid_ns_for_children.

> @@ -166,6 +166,9 @@ struct pid *alloc_pid(struct pid_namespace *ns)
>  	struct upid *upid;
>  	int retval = -ENOMEM;
>  
> +	if (set_tid < 0 || set_tid >= pid_max)
> +		return ERR_PTR(-EINVAL);
> +
>  	pid = kmem_cache_alloc(ns->pid_cachep, GFP_KERNEL);
>  	if (!pid)
>  		return ERR_PTR(retval);
> @@ -186,12 +189,31 @@ struct pid *alloc_pid(struct pid_namespace *ns)
>  		if (idr_get_cursor(&tmp->idr) > RESERVED_PIDS)
>  			pid_min = RESERVED_PIDS;
>  
> -		/*
> -		 * Store a null pointer so find_pid_ns does not find
> -		 * a partially initialized PID (see below).
> -		 */
> -		nr = idr_alloc_cyclic(&tmp->idr, NULL, pid_min,
> -				      pid_max, GFP_ATOMIC);
> +		if (set_tid) {
> +			/*
> +			 * Also fail if a PID != 1 is requested
> +			 * and no PID 1 exists.
> +			 */
> +			nr = -EINVAL;
> +			if (set_tid == 1 || !idr_is_empty(&tmp->idr))

On the second thought, I think we should check ns->child_reaper != NULL
rather than !idr_is_empty(), this looks more robust and clean.

And this way alloc_pid() can do everything lockless at the start,

	if (set_tid) {
		if (set_tid < 0 || set_tid >= pid_max)
			return ERR_PTR(-EINVAL);
		if (set_tid != 1 && !ns->child_reaper)
			return ERR_PTR(-EINVAL);
		if (!ns_capable(ns->user_ns, CAP_SYS_ADMIN))
			return ERR_PTR(-EPERM);
	}


and just for record... this is off-topic and I need to recheck, but
today "ns->pid_allocated = 0" in free_pid() doesn't look right to me...
This logic predates unshare(CLONE_PIDNS).

Oleg.


  parent reply	other threads:[~2019-08-12 16:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-11 20:33 [PATCH v5 1/2] fork: extend clone3() to support CLONE_SET_TID Adrian Reber
2019-08-11 20:33 ` [PATCH v5 2/2] selftests: add tests for clone3() Adrian Reber
2019-08-11 21:37   ` Christian Brauner
2019-08-12  9:40 ` [PATCH v5 1/2] fork: extend clone3() to support CLONE_SET_TID Christian Brauner
2019-08-12 16:37 ` Oleg Nesterov [this message]
2019-08-12 16:51   ` Christian Brauner
2019-08-12 16:57     ` Oleg Nesterov
2019-08-12 17:05       ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190812163710.GC31560@redhat.com \
    --to=oleg@redhat.com \
    --cc=0x7f454c46@gmail.com \
    --cc=areber@redhat.com \
    --cc=avagin@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=rstoyanov1@gmail.com \
    --cc=xemul@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.