public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Mateusz Guzik <mjguzik@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: brauner@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] pid: cosmetic changes to alloc_pid()
Date: Sat, 7 Mar 2026 10:23:45 +0100	[thread overview]
Message-ID: <aavuocRuM2Kmwj98@redhat.com> (raw)
In-Reply-To: <20260306190100.1900572-1-mjguzik@gmail.com>

On 03/06, Mateusz Guzik wrote:
>
> Commit 6d864a1b182532e7 ("pid: only take pidmap_lock once on alloc")
> landed v2 of the patch instead of v3. This patch remedies the problem.
>
> No functional changes.
>
> Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>

The patch looks obviously good, but it conflicts with Pavel's

	[PATCH v4 0/4] pid_namespace: make init creation more flexible
	https://lore.kernel.org/all/20260225133229.550302-1-ptikhomirov@virtuozzo.com/#t

In particular, this change:

 -     for (tmp = ns, i = ns->level; i >= 0; i--) {
 +     for (tmp = ns, i = ns->level; i >= 0;) {

With 2/4 from Pavel we need to decrement "i" before the ->child_reaper
check.

Pavel, it seems you need to resend your series anyway, may be on top
of this patch, I dunno. And probably this all should be routed via
-mm tree?

Oleg.

> ---
>  kernel/pid.c | 19 +++++++++----------
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 2f1dbcbc2349..dbe82062e683 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -177,7 +177,7 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  	 * for a process in all nested PID namespaces but arg_set_tid_size must
>  	 * never be greater than the current ns->level + 1.
>  	 */
> -	if (arg_set_tid_size > ns->level + 1)
> +	if (unlikely(arg_set_tid_size > ns->level + 1))
>  		return ERR_PTR(-EINVAL);
>  
>  	/*
> @@ -186,7 +186,7 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  	 * 1. allocate and fill in pid struct
>  	 */
>  	pid = kmem_cache_alloc(ns->pid_cachep, GFP_KERNEL);
> -	if (!pid)
> +	if (unlikely(!pid))
>  		return ERR_PTR(retval);
>  
>  	get_pid_ns(ns);
> @@ -205,7 +205,7 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  	 * This stores found pid_max to make sure the used value is the same should
>  	 * later code need it.
>  	 */
> -	for (tmp = ns, i = ns->level; i >= 0; i--) {
> +	for (tmp = ns, i = ns->level; i >= 0;) {
>  		pid_max[ns->level - i] = READ_ONCE(tmp->pid_max);
>  
>  		if (arg_set_tid_size) {
> @@ -227,6 +227,7 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  		}
>  
>  		tmp = tmp->parent;
> +		i--;
>  	}
>  
>  	/*
> @@ -247,10 +248,9 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  				       tid + 1, GFP_ATOMIC);
>  			/*
>  			 * If ENOSPC is returned it means that the PID is
> -			 * alreay in use. Return EEXIST in that case.
> +			 * already in use. Return EEXIST in that case.
>  			 */
>  			if (nr == -ENOSPC)
> -
>  				nr = -EEXIST;
>  		} else {
>  			int pid_min = 1;
> @@ -276,12 +276,11 @@ struct pid *alloc_pid(struct pid_namespace *ns, pid_t *arg_set_tid,
>  			 * Preload more memory if idr_alloc{,cyclic} failed with -ENOMEM.
>  			 *
>  			 * The IDR API only allows us to preload memory for one call, while we may end
> -			 * up doing several under pidmap_lock with GFP_ATOMIC. The situation may be
> -			 * salvageable with GFP_KERNEL. But make sure to not loop indefinitely if preload
> -			 * did not help (the routine unfortunately returns void, so we have no idea
> -			 * if it got anywhere).
> +			 * up doing several with GFP_ATOMIC. It may be the situation is salvageable with
> +			 * GFP_KERNEL. But make sure to not loop indefinitely if preload did not help
> +			 * (the routine unfortunately returns void, so we have no idea if it got anywhere).
>  			 *
> -			 * The lock can be safely dropped and picked up as historically pid allocation
> +			 * The pidmap lock can be safely dropped and picked up as historically pid allocation
>  			 * for different namespaces was *not* atomic -- we try to hold on to it the
>  			 * entire time only for performance reasons.
>  			 */
> -- 
> 2.48.1
> 



  reply	other threads:[~2026-03-07  9:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06 19:01 [PATCH] pid: cosmetic changes to alloc_pid() Mateusz Guzik
2026-03-07  9:23 ` Oleg Nesterov [this message]
2026-03-07 10:31   ` Mateusz Guzik
2026-03-07 12:11     ` Oleg Nesterov
2026-03-13 12:05       ` Pavel Tikhomirov

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=aavuocRuM2Kmwj98@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mjguzik@gmail.com \
    --cc=ptikhomirov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox