[lkml]   [2009]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ia64: prevent irq migration race in __cpu_disable path
* Luck, Tony <>:
> > This is wrong because fixup_irqs calls migrate_irqs, and in
> > migrate_irqs, we use the cpu_online_map to:
> >
> > 1. look for interrupts on current CPU
> > 2. if we find one, move it to the first available CPU in
> > the cpu_online_map
> >
> > This means we can potentially migrate an interrupt off ourself
> > back to... ourself. Uh oh.
> Should we make migrate_irqs smarter then ... does any caller really
> expect that it would "migrate" the irq to the same cpu?

The only thing migrate_irqs does is locate irqs that have their
CPU affinity set to the current CPU, and if so, changes the

We still have possible pending timer interrupts that we need to
handle, so I'm not seeing how changing the migrate_irqs
implementation (to avoid migrating to ourself) will handle that.

On one hand, I think the only irq handler that can be called at
this point is our timer_interrupt, which doesn't seem to be using
any RCU APIs.

On the other hand, if we really want to make sure that we're not
calling interrupt handlers with our CPU marked as 'offline', then
we need to fix ia64_process_pending_intr() so that we're not
firing our timer_interrupt with a NULL pt_regs.

Add in to the mix that x86 seems to have the same assumption that
we do (that it's ok to call our timer interrupt handler even if
we're already marked as 'offline').

I'm leaning towards reverting Paul's previous commit entirely

- migrate_platform_irqs() doesn't cause any interrupt
handlers to be fired by itself

- it also uses cpu_online)map to find a new CPU to assign



 \ /
  Last update: 2009-02-06 22:09    [W:0.056 / U:0.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site