On Thu, 28 Jan 1999 03:50:39 +0100 (CET), Andrea Arcangeli
<andrea@e-mind.com> said:
> Do you want to know why last night I added a spinlock around mmget/mmput
> without thinking twice? Simply because mm->count was an atomic_t while it
> doesn't need to be an atomic_t in first place.
Agreed.
> So you don't buy my code, but now, I don't buy both all /proc mmget/mmput
> sutff and the mm->count atomic_t.
Agreed. mm->count might as well remain atomic because that will help
when we come to apply finer grained locking to the mm, but as far as I
am concerned we may as well drop pretty much all of the mmget/mmput
stuff. The only race I can still see is the possibility of sys_wait*
removing the task struct while we run on SMP.
> I also removed all the memcpy, we only need the read_lock(tasklist_lock)
> held in SMP because otherwise wait4() could remove the stack of the
> process under our eyes as just pointed out in the last email.
Yep, fine, as long as we keep the tasklist_lock right until the end of
our use of the task struct.
> Not doing in 2.2.1 the mm->count s/atomic_t/int/ due worry of races will
> mean that array.c in 2.2.1 will be not safe enough without my mm_lock
> spinlock. Do you understand my point?
No, because we already have a sufficient spinlock to protect us.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/