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.
next prev parent 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.