Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965477AbaKNLXG (ORCPT ); Fri, 14 Nov 2014 06:23:06 -0500 Received: from mail-wg0-f50.google.com ([74.125.82.50]:43538 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965074AbaKNLVz (ORCPT ); Fri, 14 Nov 2014 06:21:55 -0500 From: Daniel Thompson To: Steven Rostedt , Ingo Molnar Cc: Daniel Thompson , kgdb-bugreport@lists.sourceforge.net, linux-kernel@vger.kernel.org, Andrew Morton , patches@linaro.org, linaro-kernel@lists.linaro.org, John Stultz , Sumit Semwal , Jason Wessel Subject: [PATCH 3.18-rc3 v3 1/2] trace: kdb: Fix kernel panic during ftdump Date: Fri, 14 Nov 2014 11:21:22 +0000 Message-Id: <1415964083-10354-2-git-send-email-daniel.thompson@linaro.org> X-Mailer: git-send-email 1.9.3 In-Reply-To: <1415964083-10354-1-git-send-email-daniel.thompson@linaro.org> References: <1415277716-19419-1-git-send-email-daniel.thompson@linaro.org> <1415964083-10354-1-git-send-email-daniel.thompson@linaro.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently kdb's ftdump command unconditionally crashes due to a null pointer de-reference whenever the command is run. This in turn causes the kernel to panic. The abridged stacktrace (gathered with ARCH=arm) is: -~- cut here -~- [] (panic) from [] (die+0x264/0x440) [] (die) from [] (__do_kernel_fault.part.11+0x74/0x84) [] (__do_kernel_fault.part.11) from [] (do_page_fault+0x1d0/0x3c4) [] (do_page_fault) from [] (do_DataAbort+0x48/0xac) [] (do_DataAbort) from [] (__dabt_svc+0x38/0x60) Exception stack(0xc0deba88 to 0xc0debad0) ba80: e8c29180 00000001 e9854304 e9854300 c0f567d8 c0df2580 baa0: 00000000 00000000 00000000 c0f117b8 c0e3a3c0 c0debb0c 00000000 c0debad0 bac0: 0000672e c02f4d60 60000193 ffffffff [] (__dabt_svc) from [] (kdb_ftdump+0x1e4/0x3d8) [] (kdb_ftdump) from [] (kdb_parse+0x2b8/0x698) [] (kdb_parse) from [] (kdb_main_loop+0x52c/0x784) [] (kdb_main_loop) from [] (kdb_stub+0x238/0x490) -~- cut here -~- The NULL deref occurs due to the initialized use of struct trace_iter's buffer_iter member. This is a regression, albeit a fairly elderly one. It was introduced by commit 6d158a813efc ("tracing: Remove NR_CPUS array from trace_iterator"). This patch solves this by providing a collection of ring_buffer_iter(s) and using this to initialize buffer_iter. Note that static allocation is used solely because the trace_iter itself is also static allocated. Static allocation also means that we have to NULL-ify the pointer during cleanup to avoid use-after-free problems. Signed-off-by: Daniel Thompson Cc: Jason Wessel Cc: Steven Rostedt Cc: Ingo Molnar --- kernel/trace/trace_kdb.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/trace/trace_kdb.c b/kernel/trace/trace_kdb.c index bd90e1b06088..8faa7ce58814 100644 --- a/kernel/trace/trace_kdb.c +++ b/kernel/trace/trace_kdb.c @@ -20,10 +20,12 @@ static void ftrace_dump_buf(int skip_lines, long cpu_file) { /* use static because iter can be a bit big for the stack */ static struct trace_iterator iter; + static struct ring_buffer_iter *buffer_iter[CONFIG_NR_CPUS]; unsigned int old_userobj; int cnt = 0, cpu; trace_init_global_iter(&iter); + iter.buffer_iter = buffer_iter; for_each_tracing_cpu(cpu) { atomic_inc(&per_cpu_ptr(iter.trace_buffer->data, cpu)->disabled); @@ -86,9 +88,12 @@ out: atomic_dec(&per_cpu_ptr(iter.trace_buffer->data, cpu)->disabled); } - for_each_tracing_cpu(cpu) - if (iter.buffer_iter[cpu]) + for_each_tracing_cpu(cpu) { + if (iter.buffer_iter[cpu]) { ring_buffer_read_finish(iter.buffer_iter[cpu]); + iter.buffer_iter[cpu] = NULL; + } + } } /* -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/