[EMAIL PROTECTED] (Eric W. Biederman) writes: > Ingo Molnar <[EMAIL PROTECTED]> writes: > >> * Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> >>> Ingo would it be reasonable to get a wait queue so I can wait for an >>> irq that needs the delayed disable action to actually become masked? >> >> that might make sense, but what will do the wakeup - incidental IRQ >> arriving on the new CPU? Isnt that a bit risky - maybe the device wont >> generate IRQs for a really long time. > > I still need to test this, but I believe I have found a simpler > way to avoid irr problems during migration, and I believe the code > works equally well with either edge or level triggered interrupts. > > The idea is this: Instead of trying test for and handle when irr > occurs, simply enable local interrupts after disabling and > acknowledging the irq so that anything pending will be processed, > before we perform the migration operation. > > I don't think the edge case cares about the mask/ack order but > but masking before acking appears important for the level triggered > case, so we might as well use that order for both. > > Does this look like a sane way to handle this?
The version I would up testing is below, and it doesn't work. I still get "No irq handler for vector" warnings as well as a couple of complaints from lock/irq debugging. The debugging doesn't worry me. The fact that I don't have a good way to ensure I have no more irqs in flight does. So unless someone can find a sure way to drain the irqs in flight, I can't migrate an irq from process context, and looking at irr and handling a pending irq appears required. ' Eric static void ack_apic(unsigned int irq) { #if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE) if (unlikely((irq_desc[irq].status & IRQ_MOVE_PENDING) && (hardirq_count() == HARDIRQ_OFFSET))) { struct irq_desc *desc = irq_desc + irq; desc->chip->mask(irq); ack_APIC_irq(); /* Ensure all of the irq handlers for this irq have completed * before we migrate it. */ raw_local_irq_enable(); cpu_relax(); raw_local_irq_disable(); synchronize_irq(irq); move_masked_irq(irq); desc->chip->unmask(irq); return; } #endif ack_APIC_irq(); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/