linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: tj@kernel.org, linuxppc-dev@ozlabs.org,
	linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH 1/6] dump_stack: Support adding to the dump stack arch description
Date: Tue, 5 May 2015 14:16:47 -0700	[thread overview]
Message-ID: <20150505141647.a1529e46f5ba42645264769c@linux-foundation.org> (raw)
In-Reply-To: <1430824337-15339-1-git-send-email-mpe@ellerman.id.au>

On Tue,  5 May 2015 21:12:12 +1000 Michael Ellerman <mpe@ellerman.id.au> wrote:

> Arch code can set a "dump stack arch description string" which is
> displayed with oops output to describe the hardware platform.
> 
> It is useful to initialise this as early as possible, so that an early
> oops will have the hardware description.
> 
> However in practice we discover the hardware platform in stages, so it
> would be useful to be able to incrementally fill in the hardware
> description as we discover it.
> 
> This patch adds that ability, by creating dump_stack_add_arch_desc().
> 
> If there is no existing string it behaves exactly like
> dump_stack_set_arch_desc(). However if there is an existing string it
> appends to it, with a leading space.
> 
> This makes it easy to call it multiple times from different parts of the
> code and get a reasonable looking result.

Some example output in the changelog would be useful, to help people
understand the value.  In particular, is there any convention for how
these fields should be presented?  "name:value name:value", etc?  Or it
is just put random stuff in there, hopefully with self-evident
meanings.

We're going to blow out the 128 byte dump_stack_arch_desc_str[] pretty
quickly.  Is dynamic allocation a possibility?

>  /**
> + * dump_stack_add_arch_desc - add arch-specific info to show with task dumps
> + * @fmt: printf-style format string
> + * @...: arguments for the format string
> + *
> + * See dump_stack_set_arch_desc() for why you'd want to use this.
> + *
> + * This version adds to any existing string already created with either
> + * dump_stack_set_arch_desc() or dump_stack_add_arch_desc(). If there is an
> + * existing string a space will be prepended to the passed string.
> + */
> +void __init dump_stack_add_arch_desc(const char *fmt, ...)
> +{
> +	va_list args;
> +	int pos, len;
> +	char *p;
> +
> +	/*
> +	 * If there's an existing string we snprintf() past the end of it, and
> +	 * then turn the terminating NULL of the existing string into a space
> +	 * to create one string separated by a space.
> +	 *
> +	 * If there's no existing string we just snprintf() to the buffer, like
> +	 * dump_stack_set_arch_desc(), but without calling it because we'd need
> +	 * a varargs version.
> +	 */
> +
> +	len = strnlen(dump_stack_arch_desc_str, sizeof(dump_stack_arch_desc_str));
> +	pos = len;
> +
> +	if (len)
> +		pos++;
> +
> +	if (pos >= sizeof(dump_stack_arch_desc_str))
> +		return; /* Ran out of space */
> +
> +	p = &dump_stack_arch_desc_str[pos];
> +
> +	va_start(args, fmt);
> +	vsnprintf(p, sizeof(dump_stack_arch_desc_str) - pos, fmt, args);
> +	va_end(args);

This code is almost race-free.  A (documented) smp_wmb() in here would
make that 100%?

> +	if (len)
> +		dump_stack_arch_desc_str[len] = ' ';
> +}
> +

  parent reply	other threads:[~2015-05-05 21:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05 11:12 [PATCH 1/6] dump_stack: Support adding to the dump stack arch description Michael Ellerman
2015-05-05 11:12 ` [PATCH 2/6] powerpc: Add cpu name to " Michael Ellerman
2015-05-06 23:50   ` Michael Neuling
2015-05-05 11:12 ` [PATCH 3/6] powerpc: Add device-tree model " Michael Ellerman
2015-05-05 11:12 ` [PATCH 4/6] powerpc: Add ppc_md.name " Michael Ellerman
2015-05-05 11:12 ` [PATCH 5/6] powerpc/powernv: Add opal details " Michael Ellerman
2015-05-05 11:12 ` [PATCH 6/6] powerpc/pseries: Add firmware " Michael Ellerman
2015-05-05 21:16 ` Andrew Morton [this message]
2015-05-06  0:13   ` [PATCH 1/6] dump_stack: Support adding to the " Michael Ellerman
2015-05-08  6:59   ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150505141647.a1529e46f5ba42645264769c@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).