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