Messages in this thread | | | From | "liwei (GF)" <> | Subject | Re: [RFC PATCH] irqchip/gic-v3: Make gic_handle_irq() notrace | Date | Wed, 3 Apr 2019 23:23:29 +0800 |
| |
Hi Julien,
On 2019/4/2 22:00, Julien Thierry wrote: I meet this issue by coincidence before too.
> I finally found out what happens. > > When using interrupt priority masking, at the begining of > gic_handle_irq(), we are in this awkward state where we still have the I > bit set and PMR unmasked (this is because we cannot ack the interrupt > that was signaled if it has lower priority than the current priority mask). > > To try and keep things simple, we decided that local_irq_*() would only > deal with PMR (when using priority masking). With one additional case > being that, if PSR.I is set when saving flags, we'd represent it in the > form of a value of PMR (i.e. GIC_PRIO_IRQOFF), so that irqs_disabled() > and such would still accurately state that no interrupt could happen in > those sections. The assumption was that in the few sections were we are > having the PSR.I set, we wouldn't care about having interrupts disabled > with PSR.I or PMR. And now that assumption appears to be wrong: I am confused of the logic of the save and restore here, why can't we do the save & restore exactly?
> trace_graph_entry(), called at the begining of gic_handle_irq() when > enabling the tracer, does use local_irq_save/restore(). The save > operation returns flags GIC_PRIO_IRQOFF (because PSR.I is set when we > enter gic_handle_irq() ). The restore operation will then proceed to > mask PMR, once we get back to gic_handle_irq() we can't acknowledge the > interrupt we just received... > > The function tracer does not appear to save/restore flags on function > entry (I saw save/restore operations in the stack tracer but for some > reason couldn't get them to trigger the issue). > > To confirm this, I checked with the following diff (which is not a fix, > it is better to mark gic_handle_irq() as notrace if I don't find > something more suitable). > I am convinced a notrace marking here will walkaround this issue,but i am afraid there is still some trouble like this else. I send my modification to solve this issue just now, it is tested ok so far, but i am not particularly sure, could you please have a look?
Thanks, Wei
| |