[mythtv-commits] Ticket #5269: Race condition in mythshutdown
MythTV
mythtv at cvs.mythtv.org
Tue Apr 29 04:31:44 UTC 2008
#5269: Race condition in mythshutdown
--------------------------+-------------------------------------------------
Reporter: anonymous | Owner: ijr
Type: defect | Status: new
Priority: minor | Milestone: unknown
Component: mythshutdown | Version: 0.21-fixes
Severity: medium | Mlocked: 0
--------------------------+-------------------------------------------------
It looks like there may be a race condition in mythshutdown because the
fetch and the update for the increment and decrement are done as as two
different statements instead of a single atomic operation or being wrapped
in a transaction to ensure consistency. The window is relatively narrow
but since there are multiple system calls involved rescheduling is very
possible. The issue here is that you don't get reliable reversability with
multiple callers as was clearly intended. It's possible to have a sequence
of --lock or --unlock operations leave the system in either state because
they could be working on stale data
For example consider the following interleaved sequence:
Script A runs "mythshutdown -l"
mythshutdown A fetches 0
Script B runs "mythshutdown -l"
mythshutdown B also fetches 0
mythshutdown A stores 1
mythshutdown B stores 1
The correct value should have been 2, and because it's not, the first
script that runs "mythshutdown -u" will unlock for both and leave the
other caller unprotected. The same type of thing can end up with
interleaved unlocks leaving the system locked when it should be unlocked.
--
Ticket URL: <http://svn.mythtv.org/trac/ticket/5269>
MythTV <http://www.mythtv.org/>
MythTV
More information about the mythtv-commits
mailing list