On 11/01/15 23:37, Steven Rostedt wrote:

On Fri, 9 Jan 2015 16:48:01 +0000
Russell King - ARM Linux [off-list ref] wrote:

quoted

On Mon, Jan 05, 2015 at 10:19:25AM -0500, Steven Rostedt wrote:

quoted

On Mon,  5 Jan 2015 14:54:58 +0000
Daniel Thompson [off-list ref] wrote:

quoted

+/* For reliability, we're prepared to waste bits here. */
+static DECLARE_BITMAP(backtrace_mask, NR_CPUS) __read_mostly;
+static  cpumask_t printtrace_mask;
+
+#define NMI_BUF_SIZE		4096
+
+struct nmi_seq_buf {
+	unsigned char		buffer[NMI_BUF_SIZE];
+	struct seq_buf		seq;
+};

Am I missing something or does this limit us to 4096 characters of
backtrace output per CPU?

quoted

This is the same code as in x86. I wonder if we should move the
duplicate code into kernel/printk/ and have it compiled if the arch
requests it (CONFIG_ARCH_WANT_NMI_PRINTK or something). That way we
don't have 20 copies of the same nmi_vprintk() and later find that we
need to change it, and have to change it in 20 different archs.

Agreed, though I wonder about the buffer size.

Have we had kernel back traces bigger than that? Since the stack size
is limited to page size, it would seem dangerous if backtraces filled
up a page size itself, as most function frames are bigger than the
typical 60 bytes of data per line.

We could change that hard coded 4096 to PAGE_SIZE, for those archs with
bigger pages.

I've just updated the patchset with a couple of patches to common up the
printk code between arm and x86.

Just for the record I haven't changed the hard coded 4096 as part of
this. I'd be quite happy to but I didn't want to introduce any "secret"
changes to the code whilst the patch header claims I am just copying stuff.


Daniel.

Also, if the backtrace were to fill up that much. Most the pertinent
data from a back trace is at the beginning of the trace. Seldom do we
care about the top most callers (bottom of the output).

-- Steve