Otpvondoiats opened a new pull request, #18209: URL: https://github.com/apache/nuttx/pull/18209
fix deadlock about set_nonwakeup. *Note: Please adhere to [Contributing Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).* ## Summary This patch fixes a critical deadlock issue in the sensor_update_nonwakeup() function that occurs when updating the sensor's non-wakeup mode. Problem Description A deadlock can occur in the sensor framework when calling lower->ops->set_nonwakeup() while holding the upper->lock mutex. The deadlock scenario happens when: Thread A calls sensor_update_nonwakeup() and acquires upper->lock Thread A enters the code path where nonwakeup != upper->state.nonwakeup is true Thread A calls lower->ops->set_nonwakeup() while still holding the lock The lower-level driver's set_nonwakeup() implementation may need to call back into the upper layer (e.g., via RPMSG communication or ioctl) This callback attempts to acquire upper->lock again → Deadlock Root Cause The problem is that the mutex is only released after the lower driver callback completes, but the callback itself may need to acquire the same mutex for operations ## Impact Users Critical Bug Fix: Eliminates random system hangs when changing sensor power modes Improved Reliability: Multi-core sensor applications no longer experience deadlocks Better Responsiveness: Sensor mode changes complete without blocking Multi-Core Systems RPMSG Communication: Fixes deadlock in sensor RPMSG driver when remote core responds to nonwakeup ioctl Concurrent Operations: Multiple threads can safely change sensor modes simultaneously Power Management: Nonwakeup mode transitions work reliably in low-power scenarios Performance Reduced Lock Contention: Lock is held for shorter duration (only during state update) No Blocking: Lower driver callbacks no longer blocked by mutex Improved Throughput: Sensor operations can proceed while mode is being updated Compatibility No API Changes: Fix is internal to sensor framework implementation Backward Compatible: Existing drivers and applications work without modification Safe: More correct locking semantics reduce risk of future issues ## Testing ~~~ ap> uorb_listener sensor_accel[01/28 03:31:38] [25] [cp] [635][pm_mgr]: pm_timeout_callback, addr:78:F2:38:16:85:E3, profile_id:7, pm_action:16 [01/28 03:31:38] [25] [cp] [440][pm_mgr]: pm_request_sniff, peer_addr:78:F2:38:16:85:E3, max:800, min:400, attempt:4, timeout:1 [01/28 03:31:38] [ 0] [cp] [HCID] [mode change]: (0x6800ff91): [01/28 03:31:38] [ 0] [cp] 0000 04 14 06 00 81 00 02 20 03 ....... . [01/28 03:31:38] [25] [cp] [829][pm_mgr]: bt_pm_remote_link_mode_changed, addr:78:F2:38:16:85:E3, mode:1, sniff_interval:800 Mointor objects num:1 object_name:sensor_accel, object_instance:0 sensor_accel(now:1350410557200):timestamp:492687404065,x:0.033414,y:-0.667011,z:9.863746,temperature:27.693359 sensor_accel(now:1350410557500):timestamp:492687444375,x:0.047779,y:-0.681376,z:9.789525,temperature:27.693359 sensor_accel(now:1350410558900):timestamp:492687484685,x:0.102846,y:-0.638281,z:9.808679,temperature:27.693359 sensor_accel(now:1350410560300):timestamp:492687524995,x:0.071721,y:-0.592791,z:9.837410,temperature:27.693359 sensor_accel(now:1350410561700):timestamp:492687565305,x:0.014260,y:-0.688559,z:9.811073,temperature:27.693359 sensor_accel(now:1350410563100):timestamp:492687605615,x:0.050174,y:-0.607156,z:9.808679,temperature:27.693359 sensor_accel(now:1350410564400):timestamp:492687645925,x:0.069327,y:-0.640675,z:9.756006,temperature:27.693359 sensor_accel(now:1350410565800):timestamp:492687686235,x:0.019049,y:-0.645463,z:9.830227,temperature:27.693359 sensor_accel(now:1350410567200):timestamp:492687726545,x:0.040597,y:-0.585608,z:9.794313,temperature:27.693359 sensor_accel(now:1350410568600):timestamp:492687766855,x:0.026231,y:-0.609550,z:9.832622,temperature:27.693359 sensor_accel(now:1350410960200):timestamp:492687807155,x:0.076510,y:-0.602368,z:9.863746,temperature:27.755859 sensor_accel(now:1350410960400):timestamp:492687847455,x:0.045385,y:-0.652646,z:9.856564,temperature:27.755859 sensor_accel(now:1350410961800):timestamp:492687887755,x:0.054962,y:-0.671800,z:9.837410,temperature:27.755859 sensor_accel(now:1350410963200):timestamp:492687928055,x:0.028626,y:-0.707713,z:9.823045,temperature:27.755859 sensor_accel(now:1350410964600):timestamp:492687968355,x:0.078904,y:-0.645463,z:9.858957,temperature:27.755859 sensor_accel(now:1350410966000):timestamp:492688008655,x:0.069327,y:-0.633492,z:9.756006,temperature:27.755859 sensor_accel(now:1350410967300):timestamp:492688048955,x:0.035808,y:-0.671800,z:9.914024,temperature:27.755859 sensor_accel(now:1350410968700):timestamp:492688089255,x:0.095663,y:-0.695742,z:9.837410,temperature:27.755859 sensor_accel(now:1350410970100):timestamp:492688129555,x:0.069327,y:-0.741232,z:9.856564,temperature:27.755859 sensor_accel(now:1350410971500):timestamp:492688169855,x:0.074116,y:-0.595185,z:9.791920,temperature:27.755859 Object name:sensor_accel0, recieved:20 Total number of received Message:20/20 ap> uorb_listener -i sensor_accel Topic [sensor_accel0] info: name:BMI270 Accelerometer vendor:Bosch version:3 power:0.010000 max_range:78.480003 resolution:0.002400 min_delay:20000 max_delay:40000 fifo_reserved_event_count:40 fifo_max_event_count:40 ap> [01/28 03:31:46] [ 0] [audio] CPU USAGE: busy=1 cpu_sleep=0 bus_sleep=0 subsys_sleep=99(pd) ~~~ -- 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]
