All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel.thompson@linaro.org (Daniel Thompson)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/7] printk: Simple implementation for NMI backtracing
Date: Thu, 19 Mar 2015 18:48:10 +0000	[thread overview]
Message-ID: <550B19EA.6000202@linaro.org> (raw)
In-Reply-To: <20150319183037.GT23123@twins.programming.kicks-ass.net>

On 19/03/15 18:30, Peter Zijlstra wrote:
> On Thu, Mar 19, 2015 at 01:39:58PM -0400, Steven Rostedt wrote:
>>> +void printk_nmi_backtrace_complete(void)
>>> +{
>>> +	struct nmi_seq_buf *s;
>>> +	int len, cpu, i, last_i;
>>> +
>>> +	/*
>>> +	 * Now that all the NMIs have triggered, we can dump out their
>>> +	 * back traces safely to the console.
>>> +	 */
>>> +	for_each_possible_cpu(cpu) {
>>> +		s = &per_cpu(nmi_print_seq, cpu);
>>> +		last_i = 0;
>>> +
>>> +		len = seq_buf_used(&s->seq);
>>> +		if (!len)
>>> +			continue;
>>> +
>>> +		/* Print line by line. */
>>> +		for (i = 0; i < len; i++) {
>>> +			if (s->buffer[i] == '\n') {
>>> +				print_seq_line(s, last_i, i);
>>> +				last_i = i + 1;
>>> +			}
>>> +		}
>>> +		/* Check if there was a partial line. */
>>> +		if (last_i < len) {
>>> +			print_seq_line(s, last_i, len - 1);
>>> +			pr_cont("\n");
>>> +		}
>>> +
>>> +		/* Wipe out the buffer ready for the next time around. */
>>> +		seq_buf_clear(&s->seq);
>>> +	}
>>> +
>>> +	clear_bit(0, &nmi_print_flag);
>>> +	smp_mb__after_atomic();
>>
>> Is this really necessary. What is the mb synchronizing?
>>
>> [ Added Peter Zijlstra to confirm it's not needed ]
>
> It surely looks suspect; and it lacks a comment, which is a clear sign
> its buggy.
>
> Now it if tries to order the accesses to the seqbuf againt the clearing
> of the bit one would have expected a _before_ barrier, not an _after_.

It's nothing to do with the seqbuf since I added the seqbuf code myself 
but the barrier was already in the code that I copied from.

In the mainline code today it looks like this as part of the x86 code 
(note that call to put_cpu() in my patchset but it lives in the arch/ 
specific code rather than the generic code):

:                 /* Check if there was a partial line. */
:                 if (last_i < len) {
:                         print_seq_line(s, last_i, len - 1);
:                         pr_cont("\n");
:                 }
:         }
:
:         clear_bit(0, &backtrace_flag);
:         smp_mb__after_atomic();
:         put_cpu();
: }

The barrier was not intended to have anything to do with put_cpu() 
either though since the barrier was added before put_cpu() arrived:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=554ec063982752e9a569ab9189eeffa3d96731b2

There's nothing in the commit comment explaining the barrier and I 
really can't see what it is for.


Daniel.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org, patches@linaro.org,
	linaro-kernel@lists.linaro.org,
	John Stultz <john.stultz@linaro.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Andrew Thoelke <andrew.thoelke@arm.com>,
	Dongdong Deng <dongdong.deng@windriver.com>
Subject: Re: [RFC PATCH 2/7] printk: Simple implementation for NMI backtracing
Date: Thu, 19 Mar 2015 18:48:10 +0000	[thread overview]
Message-ID: <550B19EA.6000202@linaro.org> (raw)
In-Reply-To: <20150319183037.GT23123@twins.programming.kicks-ass.net>

On 19/03/15 18:30, Peter Zijlstra wrote:
> On Thu, Mar 19, 2015 at 01:39:58PM -0400, Steven Rostedt wrote:
>>> +void printk_nmi_backtrace_complete(void)
>>> +{
>>> +	struct nmi_seq_buf *s;
>>> +	int len, cpu, i, last_i;
>>> +
>>> +	/*
>>> +	 * Now that all the NMIs have triggered, we can dump out their
>>> +	 * back traces safely to the console.
>>> +	 */
>>> +	for_each_possible_cpu(cpu) {
>>> +		s = &per_cpu(nmi_print_seq, cpu);
>>> +		last_i = 0;
>>> +
>>> +		len = seq_buf_used(&s->seq);
>>> +		if (!len)
>>> +			continue;
>>> +
>>> +		/* Print line by line. */
>>> +		for (i = 0; i < len; i++) {
>>> +			if (s->buffer[i] == '\n') {
>>> +				print_seq_line(s, last_i, i);
>>> +				last_i = i + 1;
>>> +			}
>>> +		}
>>> +		/* Check if there was a partial line. */
>>> +		if (last_i < len) {
>>> +			print_seq_line(s, last_i, len - 1);
>>> +			pr_cont("\n");
>>> +		}
>>> +
>>> +		/* Wipe out the buffer ready for the next time around. */
>>> +		seq_buf_clear(&s->seq);
>>> +	}
>>> +
>>> +	clear_bit(0, &nmi_print_flag);
>>> +	smp_mb__after_atomic();
>>
>> Is this really necessary. What is the mb synchronizing?
>>
>> [ Added Peter Zijlstra to confirm it's not needed ]
>
> It surely looks suspect; and it lacks a comment, which is a clear sign
> its buggy.
>
> Now it if tries to order the accesses to the seqbuf againt the clearing
> of the bit one would have expected a _before_ barrier, not an _after_.

It's nothing to do with the seqbuf since I added the seqbuf code myself 
but the barrier was already in the code that I copied from.

In the mainline code today it looks like this as part of the x86 code 
(note that call to put_cpu() in my patchset but it lives in the arch/ 
specific code rather than the generic code):

:                 /* Check if there was a partial line. */
:                 if (last_i < len) {
:                         print_seq_line(s, last_i, len - 1);
:                         pr_cont("\n");
:                 }
:         }
:
:         clear_bit(0, &backtrace_flag);
:         smp_mb__after_atomic();
:         put_cpu();
: }

The barrier was not intended to have anything to do with put_cpu() 
either though since the barrier was added before put_cpu() arrived:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=554ec063982752e9a569ab9189eeffa3d96731b2

There's nothing in the commit comment explaining the barrier and I 
really can't see what it is for.


Daniel.

  reply	other threads:[~2015-03-19 18:48 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 14:20 [RFC PATCH 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Daniel Thompson
2015-03-18 14:20 ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 1/7] serial: Emulate break using control characters Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-19 22:05   ` Peter Hurley
2015-03-19 22:05     ` Peter Hurley
2015-03-23 15:14     ` Daniel Thompson
2015-03-23 15:14       ` Daniel Thompson
2015-03-20 14:28   ` Dave Martin
2015-03-20 14:28     ` Dave Martin
2015-03-23 15:28     ` Daniel Thompson
2015-03-23 15:28       ` Daniel Thompson
2015-03-23 16:28       ` Dave Martin
2015-03-23 16:28         ` Dave Martin
2015-03-23 19:05         ` One Thousand Gnomes
2015-03-23 19:05           ` One Thousand Gnomes
2015-03-18 14:20 ` [RFC PATCH 2/7] printk: Simple implementation for NMI backtracing Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-19 17:39   ` Steven Rostedt
2015-03-19 17:39     ` Steven Rostedt
2015-03-19 18:30     ` Peter Zijlstra
2015-03-19 18:30       ` Peter Zijlstra
2015-03-19 18:48       ` Daniel Thompson [this message]
2015-03-19 18:48         ` Daniel Thompson
2015-03-19 19:01         ` Steven Rostedt
2015-03-19 19:01           ` Steven Rostedt
2015-03-23 14:51           ` Daniel Thompson
2015-03-23 14:51             ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 3/7] irqchip: gic-v3: Reset BPR during initialization Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 4/7] arm64: irqflags: Reorder the fiq & async macros Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 5/7] arm64: irqflags: Use ICC sysregs to implement IRQ masking Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 6/7] arm64: irqflags: Automatically identify I bit mis-management Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-18 14:20 ` [RFC PATCH 7/7] arm64: Add support for on-demand backtrace of other CPUs Daniel Thompson
2015-03-18 14:20   ` Daniel Thompson
2015-03-20 15:45 ` [RFC PATCH 0/7] Pseudo-NMI for arm64 using ICC_PMR_EL1 (GICv3) Dave Martin
2015-03-20 15:45   ` Dave Martin
2015-03-23 18:47   ` Daniel Thompson
2015-03-23 18:47     ` Daniel Thompson
2015-04-01 15:15     ` Dave Martin
2015-04-01 15:15       ` Dave Martin
2015-04-01 15:29       ` Marc Zyngier
2015-04-01 15:29         ` Marc Zyngier
2015-04-08 12:27         ` Daniel Thompson
2015-04-08 12:27           ` Daniel Thompson

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=550B19EA.6000202@linaro.org \
    --to=daniel.thompson@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.