public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>, kaos@sgi.com
Subject: Re: i386 IPI handlers running with hardirq_count == 0
Date: 29 Jun 2006 13:25:38 +0200	[thread overview]
Message-ID: <p73wtb0w6dp.fsf@verdi.suse.de> (raw)
In-Reply-To: <20060629021800.9a1e16f4.akpm@osdl.org>

Andrew Morton <akpm@osdl.org> writes:

> On Thu, 29 Jun 2006 19:01:17 +1000
> Keith Owens <kaos@ocs.com.au> wrote:
> 
> > Macro arch/i386/kernel/entry.S::BUILD_INTERRUPT generates the code to
> > handle an IPI and call the corresponding smp_<name> C code.
> > BUILD_INTERRUPT does not update the hardirq_count for the interrupted
> > task, that is left to the C code.  Some of the C IPI handlers do not
> > call irq_enter(), so they are running in IRQ context but the
> > hardirq_count field does not reflect this.  For example,
> > smp_invalidate_interrupt does not set the hardirq count.
> > 
> > What is the best fix, change BUILD_INTERRUPT to adjust the hardirq
> > count or audit all the C handlers to ensure that they call irq_enter()?
> > 
> 
> The IPI handlers run with IRQs disabled.  Do we need a fix?

They have to because if there was another interrupt it would execute
IRET and then clear the NMI flag in the hardware and allow nested NMIs 
which would cause all sorts of problems.

The only reason to change it would be complex callbacks in the
current handlers using notifier chains. Maybe if they're that complex they 
should become simpler? 

-Andi

  reply	other threads:[~2006-06-29 11:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-29  9:01 i386 IPI handlers running with hardirq_count == 0 Keith Owens
2006-06-29  9:18 ` Andrew Morton
2006-06-29 11:25   ` Andi Kleen [this message]
2006-06-29 17:00     ` Keith Owens
2006-06-29 20:17       ` Ingo Molnar
2006-06-29 20:47         ` Andrew Morton
2006-06-29 20:43           ` Ingo Molnar
2006-06-29 16:40   ` Keith Owens

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=p73wtb0w6dp.fsf@verdi.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=kaos@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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