Messages in this thread | | | Date | Mon, 28 Aug 2000 20:08:14 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: Hmm.. "notify_parent()". |
| |
On Mon, 28 Aug 2000, Linus Torvalds wrote:
> 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?
Umm... a) WTF do we export it? b) we are using the same thing in do_signal() on all architectures. c) generating ELF coredumps and exec.c::must_not_trace_exec() are vulnerable too. d) Where do we initialize ->p_pptr if test in the beginning of do_fork() fails? If my reading is right we have a lot more to worry about - blind access to ->p_pptr->foo happens in quite a few places. e) ptrace and signal code for different architectures seem to share a _lot_ of code. Is there any real need to duplicate it to hell and back? I didn't look deep enough into the details (yet), but it looks like a job for several helper functions in the arch-independent code, no?
- 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/
| |