Messages in this thread | | | Date | Thu, 28 Jan 1999 18:07:57 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: [patch] fixed both processes in D state and the /proc/ oopses [Re: [patch] Fixed the race that was oopsing Linux-2.2.0] |
| |
Hi,
On Thu, 28 Jan 1999 09:54:07 -0800 (PST), Linus Torvalds <torvalds@transmeta.com> said:
> On Thu, 28 Jan 1999, Stephen C. Tweedie wrote:
>> > 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.
> Incorrect, see my previous email. It may not be strictly necessary right > now due to us probably holding the kernel lock everywhere, but it is > conceptually necessary, and it is _not_ an argument for a spinlock.
Linus, we are in violent agreement: see my previous email. :) I agree with both you and Andrea that the atomic_t is not strictly necessary, and agree vigorously that removing it is wrong because it will just make the job of fine-graining the locking ever more harder. As we relax the kernel locks, the atomic_t becomes more and more important.
> The /proc code has to be fixed, but the easy fix is to just revert to the > old one as far as I can see. I shouldn't have accepted the /proc patches > in the first place, and I'm sorry I did.
Yep, but Andrea did point out what looks like at least one valid race: sys_wait* on a zombie task can remove and deallocate the task_struct without taking the global lock. Reverting the diff is the right thing for 2.2.1, but once we've done that we may need to look at either keeping the task lock until we have finished with the task_struct in array.c, or doing a memcpy on the task while we still have it locked. That does seem to be a valid fix.
--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/
| |