Messages in this thread | | | Date | Mon, 28 Aug 2000 13:54:07 -0700 (PDT) | From | Linus Torvalds <> | Subject | Hmm.. "notify_parent()". |
| |
I was looking at the pthreads signalling issues wrt child termination, and I found something that looks wrong (regardless of any pthreads issues).
"notify_parent()" uses p->p_pptr without any locking. As far as I can tell, that is wrong. It looks like it should have a read-lock on the tasklist_lock in order to not be racy (perhaps the parent does an exit on another CPU at just this moment), but it gets slightly ugly because it is already called occasionally from contexts that already have it, and in other places from contexts that do _not_ have it.
Is there some reason you can see why this isn't a bug? Fixing it looks simple, but either involves making all callers of "notify_parent()" get the tasklist lock, or by using a separate "already locked" version for the case where we have the lock before (ie "do_notify_parent()"). Issues?
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |