From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: peterz@infradead.org, tglx@linutronix.de, mingo@kernel.org,
tj@kernel.org, rusty@rustcorp.com.au, fweisbec@gmail.com,
hch@infradead.org, mgorman@suse.de, riel@redhat.com, bp@suse.de,
rostedt@goodmis.org, mgalbraith@suse.de, ego@linux.vnet.ibm.com,
paulmck@linux.vnet.ibm.com, oleg@redhat.com, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] smp: Print more useful debug info upon receiving IPI on an offline CPU
Date: Wed, 07 May 2014 02:53:19 +0530 [thread overview]
Message-ID: <536952C7.8090500@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140506133448.23f9baa4bf4fc1a09e03fd75@linux-foundation.org>
On 05/07/2014 02:04 AM, Andrew Morton wrote:
> On Tue, 06 May 2014 23:32:51 +0530 "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>
>> Today the smp-call-function code just prints a warning if we get an IPI on
>> an offline CPU. This info is sufficient to let us know that something went
>> wrong, but often it is very hard to debug exactly who sent the IPI and why,
>> from this info alone.
>>
>> In most cases, we get the warning about the IPI to an offline CPU, immediately
>> after the CPU going offline comes out of the stop-machine phase and reenables
>> interrupts. Since all online CPUs participate in stop-machine, the information
>> regarding the sender of the IPI is already lost by the time we exit the
>> stop-machine loop. So even if we dump the stack on each CPU at this point,
>> we won't find anything useful since all of them will show the stack-trace of
>> the stopper thread. So we need a better way to figure out who sent the IPI and
>> why.
>>
>> To achieve this, when we detect an IPI targeted to an offline CPU, loop through
>> the call-single-data linked list and print out the payload (i.e., the name
>> of the function which was supposed to be executed by the target CPU). This
>> would give us an insight as to who might have sent the IPI and help us debug
>> this further.
>>
>> ...
>>
>> --- a/kernel/smp.c
>> +++ b/kernel/smp.c
>> @@ -185,15 +185,28 @@ void generic_smp_call_function_single_interrupt(void)
>> {
>> struct llist_node *entry;
>> struct call_single_data *csd, *csd_next;
>> + int warn = 0;
>>
>> /*
>> * Shouldn't receive this interrupt on a cpu that is not yet online.
>> */
>> - WARN_ON_ONCE(!cpu_online(smp_processor_id()));
>> + if (unlikely(!cpu_online(smp_processor_id()))) {
>> + warn = 1;
>> + WARN_ON_ONCE(1);
>> + }
>>
>> entry = llist_del_all(&__get_cpu_var(call_single_queue));
>> entry = llist_reverse_order(entry);
>>
>> + if (unlikely(warn)) {
>> + /*
>> + * We don't have to use the _safe() variant here
>> + * because we are not invoking the IPI handlers yet.
>> + */
>> + llist_for_each_entry(csd, entry, llist)
>> + pr_warn("SMP IPI Payload: %pS \n", csd->func);
>> + }
>> +
>
> This will emit the WARN_ON a single time, but will emit the "IPI
> Payload" list every time the cpu is found to be offline. So on the
> second and successive occurrences some output will still occur.
>
> Unfortunately WARN_ON_ONCE() returns the value of `condition', not
> `__warned', so we have to hand-code things. Like this?
>
Yeah, this version looks better. Sorry for missing this earlier.
I'll incorporate this in my next version of the patchset.
Thanks a lot!
Regards,
Srivatsa S. Bhat
> void generic_smp_call_function_single_interrupt(void)
> {
> struct llist_node *entry;
> struct call_single_data *csd, *csd_next;
> static bool warned;
>
> entry = llist_del_all(&__get_cpu_var(call_single_queue));
> entry = llist_reverse_order(entry);
>
> /*
> * Shouldn't receive this interrupt on a cpu that is not yet online.
> */
> if (unlikely(!cpu_online(smp_processor_id()) && !warned)) {
> warned = true;
> WARN_ON(1);
> /*
> * We don't have to use the _safe() variant here
> * because we are not invoking the IPI handlers yet.
> */
> llist_for_each_entry(csd, entry, llist)
> pr_warn("SMP IPI Payload: %pS \n", csd->func);
> }
>
> llist_for_each_entry_safe(csd, csd_next, entry, llist) {
> csd->func(csd->info);
> csd_unlock(csd);
> }
> }
>
>
> --- a/kernel/smp.c~smp-print-more-useful-debug-info-upon-receiving-ipi-on-an-offline-cpu-fix
> +++ a/kernel/smp.c
> @@ -185,20 +185,17 @@ void generic_smp_call_function_single_in
> {
> struct llist_node *entry;
> struct call_single_data *csd, *csd_next;
> - int warn = 0;
> -
> - /*
> - * Shouldn't receive this interrupt on a cpu that is not yet online.
> - */
> - if (unlikely(!cpu_online(smp_processor_id()))) {
> - warn = 1;
> - WARN_ON_ONCE(1);
> - }
> + static bool warned;
>
> entry = llist_del_all(&__get_cpu_var(call_single_queue));
> entry = llist_reverse_order(entry);
>
> - if (unlikely(warn)) {
> + /*
> + * Shouldn't receive this interrupt on a cpu that is not yet online.
> + */
> + if (unlikely(!cpu_online(smp_processor_id()) && !warned)) {
> + warned = true;
> + WARN_ON(1);
> /*
> * We don't have to use the _safe() variant here
> * because we are not invoking the IPI handlers yet.
> _
>
next prev parent reply other threads:[~2014-05-06 21:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 18:02 [PATCH 0/2] CPU hotplug: Fix the long-standing "IPI to offline CPU" issue Srivatsa S. Bhat
2014-05-06 18:02 ` [PATCH 1/2] smp: Print more useful debug info upon receiving IPI on an offline CPU Srivatsa S. Bhat
2014-05-06 20:34 ` Andrew Morton
2014-05-06 21:23 ` Srivatsa S. Bhat [this message]
2014-05-06 22:01 ` [PATCH v2 " Srivatsa S. Bhat
2014-05-06 18:03 ` [PATCH 2/2] CPU hotplug, stop-machine: Plug race-window that leads to "IPI-to-offline-CPU" Srivatsa S. Bhat
2014-05-06 20:40 ` Andrew Morton
2014-05-06 20:42 ` Tejun Heo
2014-05-06 21:27 ` Srivatsa S. Bhat
2014-05-06 22:01 ` [PATCH v2 " Srivatsa S. Bhat
2014-05-10 3:06 ` Tejun Heo
2014-05-11 20:07 ` Srivatsa S. Bhat
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=536952C7.8090500@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bp@suse.de \
--cc=ego@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--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
Powered by JetHome