[mythtv-commits] Ticket #5269: Race condition in mythshutdown

[MythTV]

#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