[asterisk-bugs] [Zaptel 0010806]: Channel opening and unregistering race

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10806 
====================================================================== 
Reported By:                Matti
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   10806
Category:                   zaptel (the module)
Reproducibility:            sometimes
Severity:                   crash
Priority:                   normal
Status:                     new
Zaptel Version:              SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 3052 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-23-2007 03:45 CDT
Last Modified:              10-23-2007 01:11 CDT
====================================================================== 
Summary:                    Channel opening and unregistering race
Description: 
Function zt_specchan_open can have a race condition with zt_chan_unreg
resulting in crashing of the program (Asterisk) or the whole computer
during the opening of a Zap device file.
====================================================================== 

---------------------------------------------------------------------- 
 meneault - 10-23-07 01:11  
---------------------------------------------------------------------- 
You said 'Channel access in interrupt context does not need a lock if the
access is done by the driver owning the channel', two things:

- first -- I was not talking about 'chan' but 'chans' access from
interrupt context (i.e global variable holding the channels pointers in a
statement like 'chans[ms->confna]->flags').

- second -- If some driver is owner of a channel, get an interrupt and
calls zt_receive (at least it locks on the channel's lock -- this time
'chan' not 'chans'), otherwise we would go into a problem even in single
processor environment and I don't talk about multiple CPU interrupting
concurrently.

And about the lock for spans, I recommend using a different lock than the
one for 'chans' for two reasons:
- first -- This is a simple matter of clarity, you don't lock on spans
with something called chan_lock but rather span_lock (I do agree that is
only a matter of finding a better name than chan_lock but this is an
important thing when targeting at code maintainability).

- last but not least --If you look at 'chans' and 'spans' accesses you
would agree that there are quite numerous. And when accessing 'chans', you
don't necessarily access 'spans' and vice versa. This is a finer grained
locking scheme that would give much better performance. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-23-07 01:11  meneault       Note Added: 0072393                          
======================================================================