Hi, When interrupt are globally disabled, interrupt are still detected and their flag set by their specific hardware circuit. It's only their immediat processing that are disabled.
After reenabling interrupt, they will be treated right away, as their flag are still set. it would looks like the interrupt trigger Just happened. An interrupt miss is a problem if an interrupt is triggered a second time before the first one has been treated. That's When information is lost. This is impossible in some case and harmless in other. For the rest, the driver know something happens, but canot be sur of the number of triggers. As the interrupt are not lost, the driver's interrupt function is still called and has an opportunity to check it out, and act accordingly. ++ Le 21 mars 2016 08:11:54 GMT+01:00, Vishwas Srivastava <[email protected]> a écrit : >Kernel code heavily uses the spinlock primitives >spin_lock_irqsave/restore plus local interrupt disabling/ enabling, all >across the code. >Is there a possibility that the interrupts might get >missed in this small window > >disable interrupts >............. >............. <<<<<<<<<<<---------------------- >interrupts is trigerred here > >enable interrupts > > >specially when the irq >affinity has been set to the same core on which the >above mentioned code (disabling / enabling the irq's) >runs? >How the linux deals with this kind of scenario? > > >------------------------------------------------------------------------ > >_______________________________________________ >Kernelnewbies mailing list >[email protected] >http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
