From: Keith Owens <kaos@ocs.com.au>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: i386 IPI handlers running with hardirq_count == 0
Date: Fri, 30 Jun 2006 03:00:42 +1000 [thread overview]
Message-ID: <9914.1151600442@ocs3.ocs.com.au> (raw)
In-Reply-To: Your message of "29 Jun 2006 13:25:38 +0200." <p73wtb0w6dp.fsf@verdi.suse.de>
Andi Kleen (on 29 Jun 2006 13:25:38 +0200) wrote:
>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?
My question has nothing to do with NMI. I am querying inconsistent
behaviour amongst normal IPIs, this list :-
i386 function irq_enter?
smp_apic_timer_interrupt yes
smp_call_function_interrupt yes
smp_error_interrupt yes
smp_invalidate_interrupt no - why
smp_reschedule_interrupt no (does not need it)
smp_spurious_interrupt yes
smp_thermal_interrupt yes
x86_64 function irq_enter?
mce_threshold_interrupt yes
smp_apic_timer_interrupt yes
smp_call_function_interrupt yes
smp_error_interrupt yes
smp_invalidate_interrupt no - why
smp_reschedule_interrupt no (does not need it)
smp_spurious_interrupt yes
smp_thermal_interrupt yes
That is just the mach-default list, I have not checked the platforms
like voyager.
next prev parent reply other threads:[~2006-06-29 17:00 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
2006-06-29 17:00 ` Keith Owens [this message]
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=9914.1151600442@ocs3.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--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 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.