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)**:
   
   
![Image](https://github.com/user-attachments/assets/f6052e4e-2ef1-48c3-8e13-825362a22673)
   
   📖 **Linux implementation**:
   
   
![Image](https://github.com/user-attachments/assets/b3afb394-687f-4bba-86b9-6ebf6d3b2519)
   
   
   ### 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

Reply via email to