All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Gargi Sharma <gs051095@gmail.com>,
	linux-kernel@vger.kernel.org, julia.lawall@lip6.fr,
	akpm@linux-foundation.org, mingo@kernel.org,
	pasha.tatashin@oracle.com, ktkhai@virtuozzo.com
Subject: Re: [PATCH v2 2/2] pid: Remove pidhash
Date: Mon, 02 Oct 2017 11:22:44 -0400	[thread overview]
Message-ID: <1506957764.21121.122.camel@surriel.com> (raw)
In-Reply-To: <20171002152135.GB9481@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

On Mon, 2017-10-02 at 17:21 +0200, Oleg Nesterov wrote:
> Hi Rik,
> 
> On 10/02, Rik van Riel wrote:
> > 
> > Gargi and I are looking at that code, and trying to figure out
> > exactly what needs to be done to make all of this correct.
> 
> see another email I sent to Gargi a minute ago,
> 
> > 2) With pid_ns_prepare_proc out of the way, we can put all the code
> >    from below where the call to pid_ns_prepare_proc is now (except
> >    error handing) into the main loop of pid allocation, so we can
> >    do all that stuff under the pidmap_lock:
> > 
> >    for (i = ns->level; i >= 0; i--) {
> >        ...
> >        idr_alloc_cyclic(...)
> >        get_pid_ns(ns);
> >        atomic_set(&pid->count, 1);
> >        for (...)
> >             INIT_HLIST_HEAD(...)
> >        ns->nr_allocated++;
> >        ...
> >   }
> 
> I do not see how this can fix the problem with not-fully-initialized
> pid returned by find_pid_ns().
> 
> As for PIDNS_ADDING/PIDNS_HASH_ADDING, _perhaps_ we can cleanup this
> logic
> a bit and do the check earlier, but imo this needs another/separate
> change.
> 
> I'd suggest to keep the current logic and the order of initialization
> and
> just do
> 
> 	for (i = ns->level; i >= 0; i--) {
> 		...
> 
> 		// do not expose the new pid to find_pid_ns() until it
> 		// is fully initialized
> 		nr = idr_alloc_cyclic(&tmp->idr, /*pid*/ NULL, ...);
> 		...
> 	}
> 
> 	...
> 
> 	spin_lock_irq(&pidmap_lock);
> 	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
> 		goto out_unlock;
> 	for ( ; upid >= pid->numbers; --upid) {
> -		hlist_add_head_rcu(&upid->pid_chain,
> -				&pid_hash[pid_hashfn(upid->nr, upid-
> >ns)]);
> +		// finally make it visible to find_pid_ns()
> +		idr_replace(upid->ns-idr, pid, upid->nr);
> 		upid->ns->nr_hashed++;
> 	}
> 	spin_unlock_irq(&pidmap_lock);
> 
> Or I missed something?

You are right, that would both fix the problem, and keep the error
paths relatively simple.

Gargi, what do you think?

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2017-10-02 15:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27  5:06 [PATCH v2 0/2] Replace PID bitmap allocation with IDR API Gargi Sharma
2017-09-27  5:06 ` [PATCH v2 1/2] pid: Replace pid bitmap implementation " Gargi Sharma
2017-09-27 13:09   ` Rik van Riel
2017-09-27 14:06     ` Oleg Nesterov
2017-09-27 15:06       ` Gargi Sharma
2017-09-27 15:15         ` Oleg Nesterov
2017-09-27 15:05     ` Gargi Sharma
2017-09-27 15:05   ` Oleg Nesterov
2017-10-01  9:15   ` Christoph Hellwig
2017-10-01 10:35     ` Gargi Sharma
2017-10-02 13:14       ` Rik van Riel
2017-10-02 13:05     ` Rik van Riel
2017-09-27  5:06 ` [PATCH v2 2/2] pid: Remove pidhash Gargi Sharma
2017-09-27 15:45   ` Oleg Nesterov
2017-09-27 16:28     ` Oleg Nesterov
2017-09-30 15:41       ` Gargi Sharma
2017-10-02 15:03         ` Oleg Nesterov
2017-10-02 13:35     ` Rik van Riel
2017-10-02 13:45       ` Rik van Riel
2017-10-02 15:21       ` Oleg Nesterov
2017-10-02 15:22         ` Rik van Riel [this message]
2017-10-02 16:27           ` Gargi Sharma
2017-09-27 17:18 ` [PATCH v2 0/2] Replace PID bitmap allocation with IDR API Eric W. Biederman
     [not found]   ` <CAOCi2DESqWV2YPcRTe6NYjx6m6N19ewXbAyfLfeBa23kJiEO9Q@mail.gmail.com>
2017-09-28 19:46     ` Rik van Riel
2017-09-28 20:05       ` Gargi Sharma
2017-09-29  0:35         ` Rik van Riel

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=1506957764.21121.122.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=gs051095@gmail.com \
    --cc=julia.lawall@lip6.fr \
    --cc=ktkhai@virtuozzo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=pasha.tatashin@oracle.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.