Dmitry Adamushko wrote:

On 31/12/05, *Philippe Gerum* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

 > ...

     > 2) xnintr_irq_handler() gets a cookie which is == xnshared_irq_t*
     > xnintr_attach) that may already be invalid at that time or, and
    that's a
     > problem, become invalid during the execution of xnintr_irq_handler().
     > To prevent that, we could add a flag like IRQ_INPROGRESS but
     > either we have to set/remove it on the adeos layer before the
    control is
     > passed to the xnintr_irq_handler() (to be sure that cookie is not
     > xnfree()'d. xnintr_detach() will do busy waiting)

    Synchronizing the pending IRQs in ipipe_virtualize_irq() should be done
    by polling the proper irq_pending count (and _not_ the hi/lo bits which
get cleared before the handler is run).

But irq_pending counter (pending_hits in the recent adeos patch) gets cleared before running the isr handler too.

I was referring to __ipipe_lock_irq() which clears the pending bits but keeps the irq count intact to emulate a PIC masking for a given interrupt.

In ipipe_sync_stage() :
            if (--cpudata->irq_pending_hits[irq] == 0) {

// run the corresponding isr handler

This code drops the irq_pending_hits to 0 before running the handler.

Doesn't it make the following code wrong ?

    for (_cpuid = 0; _cpuid < nr_cpus; _cpuid++)
            while (ipd->cpudata[_cpuid].irq_pending_hits[irq] > 0)

as the handler still can be running / or even about to be run when ipd->cpudata[_cpuid].irq_pending_hits[irq] is already 0.

We can remove the (*) code at the end of ipipe_sync_stage() so that irq_pending_hits[irq] may become 0 only after the corresponding isr handler has completed.

I don't like the idea of having the interrupt bookkeeping stuff incompletely updated while calling a handler that might sleep and/or migrate to another CPU.

Another option would be to check for SYNC flag; the syncer sets it before entering the dispatch loop.

At the same time, the irq_pending counter can't be increased anymore since we clear the IPIPE_HANDLE_FLAG before doing the busy waiting in ipipe_unregister_domain() or ipipe_virtualize_irq().


Best regards,
Dmitry Adamushko



Reply via email to