2f6d98bfcb
This patch introduces `rt_smp_call_request` API to handle queued requests across cores with user provided data buffer, which provides a way to request IPI through a non-blocking pattern. It also resolved several issues in the old implementation: - Multiple requests from different cores can not be queued in the work object of the target core. - Data racing on `rt_smp_work` of same core. If multiple requests came in turns, or if the call is used by the target cpu, while a new request is coming, the value will be overwrite. - Memory vulnerability. The rt_smp_event is allocated on stack, though the caller may not wait until the call is done. - API naming problem. Actually we don't provide a way to issue an IPI to ANY core in mask. What the API do is aligned to MANY pattern. - FUNC_IPI registering to PIC. Changes: - Declared and configured the new `RT_SMP_CALL_IPI` to support functional IPIs for task requests across cores. - Replaced the single `rt_smp_work` array with `call_req_cores` to manage per-core call requests safely. - Added `_call_req_take` and `_call_req_release` functions for atomic handling of request lifetimes, preventing data race conditions. - Replaced single event handling with a queue-based approach (`call_queue`) for efficient multi-request processing per core. - Introduced `rt_smp_call_ipi_handler` to process queued requests, reducing IPI contention by only sending new requests when needed. - Implemented `_smp_call_remote_request` to handle remote requests with specific flags, enabling more flexible core-to-core task signaling. - Refined `rt_smp_call_req_init` to initialize and track requests with atomic usage flags, mitigating potential memory vulnerabilities. Signed-off-by: Shell <smokewood@qq.com> |
||
|---|---|---|
| .. | ||
| dfs | ||
| drivers | ||
| fal | ||
| finsh | ||
| legacy | ||
| libc | ||
| lwp | ||
| mm | ||
| mprotect | ||
| net | ||
| utilities | ||
| vbus | ||
| Kconfig | ||
| SConscript | ||