lkml.org 
[lkml]   [2012]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: v3.4-rc2 out-of-memory problems (was Re: 3.4-rc1 sticks-and-crashs)
    On Mon, Apr 9, 2012 at 2:22 PM, David Rientjes <rientjes@google.com> wrote:
    >
    > NOTIFY_OK should never be a valid response for this notifier the way it's
    > currently implemented, it should be NOTIFY_STOP to stop iterating the call
    > chain to avoid a double free.

    No, that's no good either. That would mean that some people wouldn't
    be notified about the death of the task at all.

    So NOTIFY_STOP just implies *another* bug.

    > Right, we can't handoff the freeing of the task_struct to more than one
    > notifier.  It seems misdesigned from the beginning and what we really want
    > is to hijack task->usage for __put_task_struct(task) if we have such a
    > notifier callchain and require each one (currently just oprofile) to take
    > a reference on task->usage for NOTIFY_OK and then be responsible for
    > dropping the reference when it's done with it later instead of requiring
    > it to free the task_struct itself.

    We could make notifier.c just "or" all the return values together, and
    then it's ok if *one* person returns NOTIFY_OK.

    Of course, that's not how notifiers are documented to work, but quite
    frankly, notifiers with non-zero values that don't sat STOP are broken
    as-is anyway, so you might we well do a logical "or" of the return
    values and at least make things like this work.

    I personally think every single notifier interface we have ever had in
    the kernel has been a total f*cking disaster. The whole concept of
    "run these random functions at this random event" is a broken concept
    that just makes people do crazy broken things.

    Oh well. So my suggestion right now would be something like the
    attached. It's still horribly broken, it actively breaks documented
    notifier behavior, but dammit, if the notifier people don't like
    'or'ing return values together they should damn well return zero from
    the notifier that doesn't do anything. And returning an error will
    exit out, so..

    Hmm? Who cares about that kernel/notifier.c code? Andrew? Ingo? We
    don't have any actual maintainer for that crap, but judging by the
    commits, it's one of you two.

    Linus
    [unhandled content-type:application/octet-stream]
    \
     
     \ /
      Last update: 2012-04-10 00:13    [W:0.024 / U:30.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site