On Fri, Mar 28, 2008 at 7:52 AM, Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
But the *hardware* already does that for you - individual writes to
pointers are already atomic operations and so will be serialized.
Using a lock to guard something only does anything useful if at least
one of the critical regions that takes the lock consists of more than
a single atomic operation, or if you have a mixture of read sections
and write sections. Now it's true that your critical region in
mm_fork_init_owner() is more than a single atomic op, but I'm arguing
below that it's a no-op. So that just leaves the single region
spin_lock(&mm->owner_lock);
mm->owner = new_owner;
spin_unlock(&mm->owner_lock);
which isn't observably different if you remove the spinlock.
OK, so if the new thread has its own mm (and hence will already have
mm->owner set up to point to p in mm_init()) then we do:
which is a no-op since we know mm->owner == p.
No, I think we need to call it later - after we've cleared current->mm
(from within task_lock(current)) - so we can't rely on p->mm in this
function, we have to pass it in. If we call it before while
current->mm == mm, then we risk a race where the (new or existing)
owner exits and passes it back to us *after* we've done a check to see
if we need to find a new owner. If we ensure that current->mm != mm
before we call mm_update_next_owner(), then we know we're not a
candidate for receiving the ownership if we don't have it already.
Oops, I thought that exit_mm() already got called in the execve()
path, but you're right, it doesn't.
Yes, exit_mmap() should call mm_update_next_owner() after the call to
task_unlock(), i.e. after it's set its new mm.
So I need to express the invariant more carefully.
What we need to preserve is that, for every mm at all times, mm->owner
points to a valid task. So either:
1) mm->owner->mm == mm AND mm->owner will check to see whether it
needs to pass ownership before it exits or execs.
OR
2) mm->owner is the last user of mm and is about to free mm.
OR
3) mm->owner is currently searching for another user of mm to pass the
ownership to.
In order to get from state 3 to state 1 safely we have to hold
task_lock(new_owner). Otherwise we can race with an exit or exec in
new_owner, resulting in a process that has already passed the point of
checking current->mm->owner.
I don't see why we need mm->owner_lock to maintain this invariant.
(But am quite prepared to be proven wrong).
Paul
--
