On Mon, 17 Nov 2008, Pekka Paalanen wrote: > On Sun, 16 Nov 2008 17:35:18 +0100 (CET) > "Rafael J. Wysocki" <rjw@xxxxxxx> 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@xxxxxx> > > 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@xxxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
