Messages in this thread | | | Date | Wed, 30 Aug 2000 18:01:54 +0200 (CEST) | From | Martin Diehl <> | Subject | Re: Hmm.. "notify_parent()". |
| |
On Mon, 28 Aug 2000, Linus Torvalds wrote:
> "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?
FYI: A few days ago somebody in a local list discovered the following message in his syslog running 2.2.14 on a SMP machine:
kernel: eh? notify_parent with state 0?
It appears to me that tsk->state changed to TASK_RUNNING probably due to a race. Although he did not observe any harmful impact on his system, this might be the kind of bug you are talking about.
Martin
- 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/
| |