lkml.org 
[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHmm.. "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/

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