caoshen000 opened a new issue, #16656: URL: https://github.com/apache/nuttx/issues/16656
### Description / Steps to reproduce the issue RMW conflict on GICD_ICFGRn (without lock) CPU0 (set IRQ32 edge) CPU1 (set IRQ33 level) --------------------- ----------------------- val0 = read(ICFGRn) │ val1 = read(ICFGRn) │ val0 |= (edge << 4) │ │ val1 &= ~(3 << 6) │ write(ICFGRn, val0) │ │ write(ICFGRn, val1) => IRQ32 config lost OR IRQ33 config lost (depends on which write finishes last) ### On which OS does this issue occur? [OS: Linux] ### What is the version of your OS? Ubuntu 20.04 ### NuttX Version master ### Issue Architecture [Arch: arm], [Arch: arm64] ### Issue Area [Area: Kernel] ### Host information ### Title [Question] Should RMW access to GICD_ICFGR be protected by a lock? --- ### Background In NuttX (or a GIC-based SMP platform), the interrupt configuration register `GICD_ICFGR` is accessed to configure edge/level-triggered behavior for each interrupt. Each `ICFGRn` register is 32-bit wide and controls 16 interrupts (2 bits per IRQ). Modifying a single interrupt's configuration involves a **read-modify-write (RMW)** sequence: 1. Read full 32-bit register; 2. Mask and modify 2-bit field for the target IRQ; 3. Write back the entire 32-bit value. This introduces a race condition when multiple cores attempt to modify different IRQs within the same register concurrently. --- ### Question Should this RMW sequence be protected by a global GIC lock to avoid potential overwrites? - In the ARM GICv3 documentation, the access to `GICD_ICFGR` is not byte-addressable. - In the Linux kernel (e.g., `irq-gic-common.c`), the same access pattern is protected by a spinlock to serialize concurrent writes. --- ### Reference 📖 **ARM GICv3 Architecture Specification (IHI0069)**:  📖 **Linux implementation**:  ### Verification - [x] I have verified before submitting the report. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org