casaroli opened a new pull request, #20719: URL: https://github.com/apache/nuttx/pull/20719
## Summary Three fixes for lock waits that a signal could break. 1. `sched/semaphore`: `nxsem_wait_slow()` returns `-EINTR` at once when an unmasked signal is pending. During a system call such a signal stays pending until the call returns, so kernel code that retries a mutex wait (as `mm_lock()` does) looped. In a critical section the holder of the mutex could then not run: a 4-CPU arm64 target stopped this way. A mutex wait no longer makes this check; a signal that arrives during the wait still wakes the task through `nxsem_wait_irq()`. 2. `mm/mm_heap`: `mm_lock()` returned 0 even when `nxmutex_lock()` failed with `-EINTR`, so a task could change the heap without the lock. With SMP, parallel process creation corrupted the heap within seconds. It now retries. 3. `mm/mm_gran`: `gran_enter_critical()` returned `-EINTR`, and `gran_alloc()` then returned NULL as if the pool were full: `fork()`, `sbrk()` and new stacks failed with `ENOMEM` while most pages were free. It now retries. The order matters: 2 and 3 alone make the loop of 1 permanent, so the three go together. ## Impact Heap and page-allocator locks are no longer lost or failed by signals. No API change. ## Testing Builds: `qemu-armv8a:nsh`, `qemu-armv8a:knsh`, `lm3s6965-ek:qemu-flat`. Runtime, QEMU 11 with HVF on an Apple M4: `ostest` on `qemu-armv8a:knsh` (kernel build) and `qemu-armv8a:nsh` (flat build) ends with `ostest_main: Exiting with status 0`. `tools/checkpatch.sh -c -u -m -g` passes. The hang was found on `qemu-armv8a:knsh` with 4 CPUs, with many processes created and reaped in parallel: all CPUs waited on the critical section while one looped in `mm_lock()`. With the three commits the same load runs to the end; without the `mm_lock()`/`gran` retries the heap was corrupted within seconds. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
