mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: peterz@infradead.org, tglx@linutronix.de, mingo@kernel.org,
	tj@kernel.org, rusty@rustcorp.com.au, akpm@linux-foundation.org,
	fweisbec@gmail.com, hch@infradead.org
Cc: 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,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Subject: [PATCH 0/2] CPU hotplug: Fix the long-standing "IPI to offline CPU" issue
Date: Tue, 06 May 2014 23:32:35 +0530	[thread overview]
Message-ID: <20140506180213.14375.5904.stgit@srivatsabhat.in.ibm.com> (raw)


Hi,

There is a long-standing problem related to CPU hotplug which causes IPIs to
be delivered to offline CPUs, and the smp-call-function IPI handler code
prints out a warning whenever this is detected. Every once in a while this
(usually harmless) warning gets reported on LKML, but so far it has not been
completely fixed. Usually the solution involves finding out the IPI sender
and fixing it by adding appropriate synchronization with CPU hotplug.

However, while going through one such internal bug reports, I found that
there is a significant bug in the receiver side itself (more specifically,
in stop-machine) that can lead to this problem even when the sender code
is perfectly fine. This patchset fixes that synchronization problem in the
CPU hotplug stop-machine code.

Patch 1 adds some additional debug code to the smp-call-function framework,
to help debug such issues easily.

Patch 2 modifies the stop-machine code to ensure that any IPIs that were sent
while the target CPU was online, would be noticed and handled by that CPU
without fail before it goes offline. Thus, this avoids scenarios where IPIs
are received on offline CPUs (as long as the sender uses proper hotplug
synchronization).


In fact, I debugged the problem by using Patch 1, and found that the
payload of the IPI was always the block layer's trigger_softirq() function.
But I was not able to find anything wrong with the block layer code. That's
when I started looking at the stop-machine code and realized that there is
a race-window which makes the IPI _receiver_ the culprit, not the sender.
Patch 2 fixes that race and hence this should put an end to most of the
hard-to-debug IPI-to-offline-CPU issues.


 Srivatsa S. Bhat (2):
      smp: Print more useful debug info upon receiving IPI on an offline CPU
      CPU hotplug, stop-machine: Plug race-window that leads to "IPI-to-offline-CPU"


 kernel/smp.c          |   15 ++++++++++++++-
 kernel/stop_machine.c |   22 +++++++++++++++++++---
 2 files changed, 33 insertions(+), 4 deletions(-)


Thanks,
Srivatsa S. Bhat
IBM Linux Technology Center


             reply	other threads:[~2014-05-06 18:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-06 18:02 Srivatsa S. Bhat [this message]
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
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=20140506180213.14375.5904.stgit@srivatsabhat.in.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

all inboxes | Powered by JetHome®