The new_pages list head in the cpu_buffer is not initialized. When
adding pages to the ring buffer, if the memory allocation fails in
ring_buffer_resize, the clean up handler tries to free up the allocated
pages from all the cpu buffers. The panic is caused by referencing the
uninitialized new_pages list head.
Initializing the new_pages list head in rb_allocate_cpu_buffer fixes
this.
Signed-off-by: Vaibhav Nagarnaik <[email protected]>
---
kernel/trace/ring_buffer.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index a2bec4c..c5a5479 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1075,6 +1075,7 @@ rb_allocate_cpu_buffer(struct ring_buffer *buffer, int nr_pages, int cpu)
rb_init_page(bpage->page);
INIT_LIST_HEAD(&cpu_buffer->reader_page->list);
+ INIT_LIST_HEAD(&cpu_buffer->new_pages);
ret = rb_allocate_pages(cpu_buffer, nr_pages);
if (ret < 0)
--
1.7.7.3
On Fri, Jun 22, 2012 at 11:50 AM, Vaibhav Nagarnaik
<[email protected]> wrote:
> The new_pages list head in the cpu_buffer is not initialized. When
> adding pages to the ring buffer, if the memory allocation fails in
> ring_buffer_resize, the clean up handler tries to free up the allocated
> pages from all the cpu buffers. The panic is caused by referencing the
> uninitialized new_pages list head.
>
> Initializing the new_pages list head in rb_allocate_cpu_buffer fixes
> this.
>
> Signed-off-by: Vaibhav Nagarnaik <[email protected]>
> ---
Hi Steven,
I believe this fix should be pushed to 3.5 along with the other patch
I sent earlier:
tracing: Update entries counter when removing pages
These two patches fix issues with the recently added atomic resize patches.
Thanks
Vaibhav Nagarnaik