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    [from the cache]
©2003-2011 Jasper Spaans