Badness in xics_ipi_dispatch

[Michael Ellerman]

On Tue, 2010-04-20 at 17:17 -0500, Brian King wrote:
> In stress testing enabling and disabling of SMT, we are regularly
> seeing the badness warning below. Looking through the cpu offline
> path, this is what I see:
> 
> 1. stop_cpu: IRQ's get disabled
> 2. pseries_cpu_disable: set cpu offline (no barriers after this)
> 3. xics_migrate_irqs_away: Remove ourselves from the GIQ, but still allow
>     IPIs
> 4. stop_cpu: IRQ's get enabled again (local_irq_enable)
> 
> It looks to me like there is plenty of opportunity between 1 and 2 for
> an IPI to get queued, resulting in the badness below. Is there something
> in xics_migrate_irqs_away that should clear any pending IPIs? If there
> is, maybe the solution is as simple as adding a barrier after marking
> the cpu offline. Or is the warning bogus and we should just remove it?

It looks like xics_migrate_irqs_away() doesn't do anything about IPIs,
at least the comment says "Allow IPIs again". So I don't see what's to
stop you just taking another IPI after you reenable interrupts in
stop_cpu(). Maybe xics_ipi_dispatch() should just return if the cpu is
offline?

cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20100421/fda9f072/attachment.pgp>