Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1164665 > unrolled thread

Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late() method

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late()  method Oleg Nesterov <oleg@redhat.com> - 2015-06-13 19:50 +0200
    Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late()  method Oleg Nesterov <oleg@redhat.com> - 2015-06-14 23:00 +0200
      Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late()  method Oleg Nesterov <oleg@redhat.com> - 2015-06-15 00:20 +0200

#1164665 — Re: [PATCH 06/12] x86/mm: Enable and use the arch_pgd_init_late() method

On 06/13, Ingo Molnar wrote:
>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
> > * Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > >
> > > Afaics, we need to ensure that:
> > >
> > > > +			if (pgd_val(*pgd_src))
> > > > +				WRITE_ONCE(*pgd_dst, *pgd_src);
> > >
> > > either we notice the recent update of this PGD, or (say) the subsequent
> > > sync_global_pgds() can miss the child.
> > >
> > > How the write barrier can help?
> >
> > So the real thing this pairs with is the earlier:
> >
> > 	tsk->mm = mm;
> >
> > plus the linking of the new task in the task list.
> >
> > _that_ write must become visible to others before we do the (conditional) copy
> > ourselves.

Hmm. that write must be visible before we start to _read_ *pgd_src,
afaics.

> > Granted, it happens quite a bit earlier, and the task linking's use of locking
> > is a natural barrier - but since this is lockless I didn't want to leave a
> > silent assumption in.

I agree,

> Ah, there's another detail I forgot. This might handle the fork case, but in
> exec() we have:
>
>         tsk->mm = mm;
>         arch_pgd_init_late(mm);

Yes, this too.

But wmb() can't help. At least we need the full mb() to serialize the
STORE above (or list addition in copy_process) with the LOAD which
reads *pgd_src.

Plus we need another mb() in sync_global_pgds(), say, before the main
for_each_process() loop.


it would be nice to make this more simple/clear somehow...

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1164922

On 06/14, Ingo Molnar wrote:
>
> So since we have a spin_lock() there already,

Yeeeees, I thought about task_lock() or pgd_lock too.

> Also, since this is x86 specific code we could rely on the fact that
> spinlock-acquire is a full memory barrier?

we do not really need the full barrier if we rely on spinlock_t,
we can rely on acquire+release semantics.

Lets forget about exec_mmap(). If we add, say,

	// or unlock_wait() + barriers
	task_lock(current->group_leader);
	task_unlock(current->group_leader);

at the start of arch_pgd_init_late() we will fix the problems with
fork() even if pgd_none() below can leak into the critical section.

We rely on the fact that find_lock_task_mm() does lock/unlock too
and always starts with the group leader.

If sync_global_pgds() takes this lock first, we must see the change
in *PGD after task_unlock(). Actually right after task_lock().

Otherwise, sync_global_pgds() should see the result of list addition
if it takes this (the same) ->group_leader->lock_alloc after us.

But this is not nice, and exec_mmap() calls arch_pgd_init_late() under
task_lock().


So, unless you are going to remove pgd_lock altogether perhaps we can
rely on it the same way

	mb();
	spin_unlock_wait(&pgd_lock);
	rmb();


Avoids the barriers (and comments) on another side, but I can't say
I really like this...


So I won't argue with 2 mb's on both sides.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1164930

On 06/14, Oleg Nesterov wrote:
>
> So, unless you are going to remove pgd_lock altogether perhaps we can
> rely on it the same way
>
> 	mb();
> 	spin_unlock_wait(&pgd_lock);
> 	rmb();
>
>
> Avoids the barriers (and comments) on another side, but I can't say
> I really like this...
>
>
> So I won't argue with 2 mb's on both sides.

Or we can add

	// A new child created before can miss the PGD updates,
	// but we must see that child on the process list

	read_lock(tasklist_lock);
	read_unlock(tasklist_lock);

	// We can miss a new child forked after read_unlock(),
	// but then its parent must see all PGD updates right
	// after it does write_unlock(tasklist);

	for_each_process(p) {

before main for_each_process() loop in sync_global_pgds().

As for exec_mmap() we can rely on task_lock(), sync_global_pgds()
takes it too. The corner case is when exec changes the leader, so
exec_mmap/sync_global_pgds can take different locks. But in this
case we can rely on de_thread() (which takes tasklist for write)
by the same reason: either sync_global_pgds() will see the new
leader, or the new leader must see the updates.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web