Messages in this thread | | | Date | Sun, 16 Nov 2008 17:44:39 -0500 (EST) | From | Steven Rostedt <> | Subject | Re: [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
| |