[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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?

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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.381 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site