All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Oleg Nesterov <oleg@redhat.com>, Gargi Sharma <gs051095@gmail.com>
Cc: 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 09:45:29 -0400	[thread overview]
Message-ID: <1506951929.21121.121.camel@surriel.com> (raw)
In-Reply-To: <1506951313.21121.119.camel@surriel.com>

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

On Mon, 2017-10-02 at 09:35 -0400, Rik van Riel wrote:
> On Wed, 2017-09-27 at 17:45 +0200, Oleg Nesterov wrote:
> > On 09/27, Gargi Sharma wrote:
> > > 
> > > -#define find_next_offset(map, off)				
> > > 	
> > > \
> > > -		find_next_zero_bit((map)->page, BITS_PER_PAGE,
> > > off)
> > > -
> > 
> > this should go into the previous patch, but this is minor...
> > 
> > > @@ -208,12 +200,10 @@ struct pid *alloc_pid(struct pid_namespace
> > > *ns)
> > >  
> > >  	upid = pid->numbers + ns->level;
> > >  	spin_lock_irq(&pidmap_lock);
> > > -	if (!(ns->nr_hashed & PIDNS_HASH_ADDING))
> > > +	if (!(ns->pid_allocated & PIDNS_ADDING))
> > >  		goto out_unlock;
> > >  	for ( ; upid >= pid->numbers; --upid) {
> > > -		hlist_add_head_rcu(&upid->pid_chain,
> > > -				&pid_hash[pid_hashfn(upid->nr,
> > > upid->ns)]);
> > > -		upid->ns->nr_hashed++;
> > > +		upid->ns->pid_allocated++;
> > 
> > No, this is wrong.
> > 
> > It is too late to check PIDNS_HASH_ADDING/PIDNS_ADDING and
> > increment
> > pid_allocated,
> > once we call idr_alloc_cyclic() this pid is already "hashed" in
> > that
> > it can be found
> > by find_pid_ns() with this patch applied.
> > 
> > And of course, it is too late to do atomic_set(&pid->count, 1) and
> > initialize
> > pid->tasks[type] lists by the same reason.
> 
> Hi Oleg,
> 
> 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.
> 
> We are thinking something along these lines:

.... and we looked at the code some more. Some of the way the
code is laid out currently looks like an artifact of history.

Lets try this again:

1) pid = kmem_cache_alloc(...)

2) get_pid_ns(ns);
   atomic_set(&pid->count, 1);
   for (type = 0; ...)
       INIT_HLIST(...)


> 3) First, check if this is a new namespace (PIDNS_ADDING), and
>    do the call to pid_ns_prepare_proc, before we even call idr_alloc.
>    Maybe something like:
> 
>    if (unlikely(ns->nr_allocated == PIDNS_ADDING)) {
>       if (pid_ns_prepare_proc(ns)) {
>          disable_pid_allocations(ns);
>          goto out_free_ns;
>    }
> 
> 4) 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(...)

>        ns->nr_allocated++;
>        ...
>   }
> 
> Would that resolve your objection, or are we barking up the wrong
> tree?

Now the per-pid struct stuff is done once, before the loop, and
the loop deals only with allocated numbers inside each parent
namespace.

The error path would unwind stuff done earlier.

-- 
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 13:45 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 [this message]
2017-10-02 15:21       ` Oleg Nesterov
2017-10-02 15:22         ` Rik van Riel
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=1506951929.21121.121.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.