Messages in this thread | | | From | Ajay Garg <> | Date | Tue, 12 Dec 2023 00:44:03 +0530 | Subject | Re: Query on a rare simultaneous processing of interrupts from GIC/NVIC |
| |
Have had some discussion at the following link and following comments : linux kernel - Query on a rare simultaneous processing of interrupts from GIC/NVIC - Stack Overflow
Really wish to understand if interrupts can in fact be queued at the software side, if the sequencing mentioned occurs.
On Mon, Dec 11, 2023 at 6:36 PM Ajay Garg <ajaygargnsit@gmail.com> wrote: > > Hi everyone. > > Let's say the following code is shared by multiple ISRs : > > spin_lock_irqsave > <critical section> > spin_lock_irqrestore > > > > Also, following sequencing happens : > > * > Low-priority interrupt comes in, and GIC/NVIC causes it jump to ISR. > > * > Low-priority interrupt starts executing "spin_lock_irqsave". > > * > Before preemption and interrupts could be disabled (by the executing > low-priority interrupt). high-priority interrupt comes in. > Since a higher priority interrupt has come in, the GIC/NVIC causes it > to start executing the "spin_lock_irqsave" statement. > > * > Through the low-priority interrupt executing, "spin_lock_irqsave" has completed. > Preemption and interrupts are disabled, and low-priority interrupt > grabs the spin lock. > > * > High-priority interrupt spins on the spin-lock. > > > > Is the above sequencing possible? > > In other words, although the first interrupt did its best to disable > all preemption and interrupts before it could enter the critical > section, yet above sequencing *will* cause the high-priority interrupt > to spin? > > > Many thanks in advance for your time for help ! > > > Thanks and Regards, > Ajay
| |