Project

General

Profile

Actions

Bug #3592

open

rtl: Race Conditions

Added by xloem over 5 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/25/2018
Due date:
% Done:

0%

Spec Reference:

Description

There appear to be a handful of race conditions in the rtl library.

1. _running is set false without a lock right before _buf_cond is notified; see http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n326
_buf_cond is never notified again, so on this line http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n343
there could be an infinite hang. _running is checked inside a lock, and then _buf_cond waited on. If _running is set false in between those statements, the wait will never return.

I've attempted to fix this in http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001835.html . The patch also locks around _buf_used, which is recommended in the face of unknown compiler optimizations and target platforms by https://www.usenix.org/legacy/event/hotpar11/tech/final_files/Boehm.pdf .

2. There is no lock shared between the write to the sample buffer at http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n304 and the read from it at http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc?id=4d83c6067f059b0c5015c3f59f8117bbd361e877#n352 . When the overflow condition is hit, the buffer pointers will wrap, and corrupt data will be produced.

My approach to fixing this was to change how overflows are handled entirely in http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001832.html

Actions #1

Updated by laforge over 4 years ago

  • Assignee set to horiz0n
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)