linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	Anton Blanchard <anton@samba.org>,
	tj@kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 1/6] dump_stack: Support adding to the dump stack arch description
Date: Fri, 08 May 2015 16:59:17 +1000	[thread overview]
Message-ID: <1431068357.9673.9.camel@ellerman.id.au> (raw)
In-Reply-To: <20150505141647.a1529e46f5ba42645264769c@linux-foundation.org>

On Tue, 2015-05-05 at 14:16 -0700, Andrew Morton wrote:
> 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.
> > +
> > +	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] = ' ';
> > +}

On second thoughts I don't think it would.

It would order the stores in vsnprintf() vs the store of the space. The idea
being you never see a partially printed string. But for that to actually work
you need a barrier on the read side, and where do you put it?

The cpu printing the buffer could speculate the load of the tail of the buffer,
seeing something half printed from vsnprintf(), and then load the head of the
buffer and see the space, unless you order those loads.

So I don't think we can prevent a crashing cpu seeing a semi-printed buffer
without a lock, and we don't want to add a lock.

The other issue would be that a reader could miss the trailing NULL from the
vsnprintf() but see the space, meaning it would wander off the end of the
buffer. But the buffer's in BSS to start with, and we're careful not to print
off the end of it, so it should always be NULL terminated.

cheers



      parent reply	other threads:[~2015-05-08  6:59 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 ` [PATCH 1/6] dump_stack: Support adding to the " Andrew Morton
2015-05-06  0:13   ` Michael Ellerman
2015-05-08  6:59   ` Michael Ellerman [this message]

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=1431068357.9673.9.camel@ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --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).