[asterisk-bugs] [Zaptel 0009379]: [patch] zt_specchan_open race because ZT_FLAG_OPEN testing and setting is not atomic

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9379 
====================================================================== 
Reported By:                Matti
Assigned To:                mattf
====================================================================== 
Project:                    Zaptel
Issue ID:                   9379
Category:                   zaptel (the module)
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     assigned
Zaptel Version:             1.4.7.1  
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             03-26-2007 07:55 CDT
Last Modified:              06-04-2008 02:51 CDT
====================================================================== 
Summary:                    [patch] zt_specchan_open race because ZT_FLAG_OPEN
testing and setting is not atomic
Description: 
Function zt_specchan_open in file zaptel.c can have a race condition
because ZT_FLAG_OPEN testing and setting is not atomic. The function should
check and set the flag holding the spin lock continuously in and between
the following lines:
if (chans[unit]->flags & ZT_FLAG_OPEN)
chans[unit]->flags |= ZT_FLAG_OPEN;
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010806 Channel opening and unregistering race
====================================================================== 

---------------------------------------------------------------------- 
 tzafrir - 06-04-08 02:51  
---------------------------------------------------------------------- 
Uploaded clear_before_close.diff: a workaround for the panic mentioned in
my previous comment.

Further details: 
The close() span method decreases a reference count for the ammount of
(zaptel) channels that are held open by userspace. If we want to disconnect
the device (e.g: the USB device was unplugged) we remove the USB parts and
leave a stub connected. That stub waits for the reference count of all the
spans of this device to get to 0. When this happens, it cleans up
everything and also deregisters all the spans of the device.

Thus in this case the last close() for a channel in the device triggered
removing it and invalidating all of its channels. And the channel probably
got removed even before there was a chance to set its flags in the last
line. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-04-08 02:51  tzafrir        Note Added: 0087774                          
======================================================================