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

[Oleg Nesterov]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/