fix(smtc_modem_hal): implement RAC API mutex in protect/unprotect_api_call - #5
Mikefly123 wants to merge 1 commit into
Conversation
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…_call The RAC wraps every public entry point (engine pass included) in protect/unprotect and relies on it for mutual exclusion between the USP engine thread and API callers on other threads. The bare-metal stub shipped with this HAL did nothing, so a concurrent rp_task_enqueue()/abort against a running engine could tear the radio planner's task structs — observed as an RP_FAILSAFE panic on a LOCK_RADIO_ACCESS task whose type field read non-LOCK, and a TX launch taken through the LR-FHSS branch while on a LoRa profile. Implement protect/unprotect_api_call with a k_mutex. k_mutex allows recursive locking by the owner, which the RAC requires: post- transaction callbacks run inside the engine pass and may call smtc_rac_unlock_radio_access(), which re-enters protect. The radio/timer IRQ callbacks only set flags and never call protect, so ISR context is excluded by design; assert if a caller violates this.
bbdd729 to
c8f29ad
Compare
|
Stack position 5/6 of stack Lora-net#8: base #4. Next: #6. |
1 participant
What
Implements
smtc_modem_hal_protect_api_call()/smtc_modem_hal_unprotect_api_call()inmodules/smtc_modem_hal/smtc_modem_hal.cwith a recursive, priority-inheritancek_mutexinstead of the bare-metal no-op stub.Why
The Semtech RAC (Radio Access Controller) wraps every public entry point — including the engine pass — in protect/unprotect and relies on it for mutual exclusion between the USP engine thread and API callers on other threads. The stock stub did nothing, so a concurrent
rp_task_enqueue()/abort against a running engine could tear the radio planner's task structs. This was observed live: anRP_FAILSAFEpanic on aLOCK_RADIO_ACCESStask whose type field read non-LOCK, and a TX launch taken through the LR-FHSS branch while on a LoRa profile.k_mutexwas chosen because it allows recursive locking by the owner, which the RAC requires — post-transaction callbacks run inside the engine pass and may callsmtc_rac_unlock_radio_access(), re-entering protect. Radio/timer IRQ callbacks only set flags and never call protect, so ISR context is excluded by design (asserted).Validation