[lkml]   [2000]   [Aug]   [30]   [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:

    > "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 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.


    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.021 / U:2.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site