public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* [Linux-ia64] Re: ia64_mca_rendez_int_handler use of hard_smp_processor_id
@ 2003-03-26  2:13 Keith Owens
  0 siblings, 0 replies; only message in thread
From: Keith Owens @ 2003-03-26  2:13 UTC (permalink / raw)
  To: linux-ia64

On Wed, 26 Mar 2003 12:55:55 +1100, 
Peter Chubb <peter@chubb.wattle.id.au> wrote:
>Index: 20.5/arch/ia64/kernel/mca.c
>--- 20.5/arch/ia64/kernel/mca.c Wed, 11 Dec 2002 20:58:53 +1100 kaos (linux-2.4/s/c/5_mca.c 1.1.3.2.3.1.1.1.1.3 644)
>+++ 20.5(w)/arch/ia64/kernel/mca.c Wed, 26 Mar 2003 08:14:29 +1100 kaos (linux-2.4/s/c/5_mca.c 1.1.3.2.3.1.1.1.1.3 644)
>@@ -640,13 +640,10 @@ ia64_mca_wakeup_all(void)
> void
> ia64_mca_rendez_int_handler(int rendez_irq, void *arg, struct pt_regs *ptregs)
> {
>-	int flags, cpu = 0;
>+	int flags, cpu = smp_processor_id();
> 	/* Mask all interrupts */
> 	save_and_cli(flags);
>
>If this is called from a preemptible context, then move the cpu >cmp_processor_id() within the save_and_cli() section, or it won't be
>preempt safe.  (thread could be migrated between getting the processor
>ID and stopping interrupts.)

2.4, preempt is not my problem :).  In any case, MCA rendezvous is a
normal interrupt

  ivt.S:interrupt ->
    ia64_handle_irq ->
      ia64_mca_rendez_int_handler.

It is my understanding that the interrupt handler will not migrate off
the current cpu, even with preempt.



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-03-26  2:13 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-26  2:13 [Linux-ia64] Re: ia64_mca_rendez_int_handler use of hard_smp_processor_id Keith Owens

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox