lkml.org 
[lkml]   [2008]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug #11996] Tracing framework regression in 2.6.28-rc3

On Mon, 17 Nov 2008, Pekka Paalanen wrote:

> On Sun, 16 Nov 2008 17:35:18 +0100 (CET)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.27. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11996
> > Subject : Tracing framework regression in 2.6.28-rc3
> > Submitter : Pekka Paalanen <pq@iki.fi>
> > Date : 2008-11-09 10:13 (8 days old)
> > References : http://marc.info/?l=linux-kernel&m=122624392229317&w=4
> > Handled-By : Steven Rostedt <rostedt@goodmis.org>
>
> Steve, Ingo, did you get into an agreement on the patch?
> What should I test?
>
> I see -rc5 is out, but I didn't spot the fix in the changelog.
>
> (The ring buffer NULL dereference on resize / unallocated max tracer.)

Ingo's solution was to have the ring_buffer_resize return success on NULL
buffer being passed in. Although I agree that it should not crash when
passed a NULL pointer, I feel that a NULL pointer should return a -1
(failure). The caller of the code (one place in kernel/trace/trace.c)
could simply check if the buffer was allocated, and if not, simply ignore
it.

I agree with Ingo that my original solution was too much churn. But the
simple if statement and "indent" change is what I feel to be the solution,
not letting the ring buffer return success on NULL pointer.

-- Steve



\
 
 \ /
  Last update: 2008-11-16 23:47    [W:1.073 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site