[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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]