linux-kernel - Re: Query on a rare simultaneous processing of interrupts from GIC/NVIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHP4M8U8rUaFFRkQ2wYmT3JgKJ+g7h9nKLiqSYNdrBGLF1ckNw@mail.gmail.com>
Date:   Tue, 12 Dec 2023 00:44:03 +0530
From:   Ajay Garg <ajaygargnsit@...il.com>
To:     linux-arm-kernel@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
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@...il.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