[asterisk-bugs] [Zaptel 0011661]: ztcfg default behavior + races in zaptel drivers + unsuspecting admins cause kernel crashes

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11661 
====================================================================== 
Reported By:                sim
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   11661
Category:                   Core-General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Zaptel Version:             1.4.7.1 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-31-2007 18:29 CST
Last Modified:              01-02-2008 12:52 CST
====================================================================== 
Summary:                    ztcfg default behavior  + races in zaptel drivers +
unsuspecting admins cause kernel crashes
Description: 
I have witnessed more than 5 different people accidentally run "ztcfg" on
production systems in an attempt to try to poke at zaptel to find the
source of an issue.  One runs through "zttool", "ztdiag", "zttest", etc.,
and usually "ztcfg" if they do not know better, expecting it to behave
similar to "ifconfig".  This _should_ just reset the PRIs (in a perfect
world), but instead it tends to cause a kernel Oops in zt_init_tone_state
due to races in zaptel when channels are active.

I bet this has been causing people to kill their Asterisk servers around
the globe for many years now, and I think this is serious enough to warrant
an interface change.  I propose we either change "ztcfg" to require an
argument before applying any changes, or we make it do something similar to
checking for Asterisk running first, and not apply configuration if so
unless an override argument is specified.

If agreed, I can easily write and submit a patch -- just let me know.
====================================================================== 

---------------------------------------------------------------------- 
 sim - 01-02-08 12:52  
---------------------------------------------------------------------- 
Well, I filed this bug not regarding the Zaptel crash issues, but just
regarding the "ztcfg" default behavior, which is not actually a bug, but is
the cause of usually-unintentional PRI resets...and this happens to expose
a real bug (Zaptel races).  I think this is serious enough that it warrants
being changed even without the Zaptel issues.

I can reliably reproduce the Zaptel crash (kernel oops) by simply running
"ztcfg" on any of our normal production (with, for example, anywhere from
10-50 active PRI channels).  The kernel oops occurs very shortly after
running "ztcfg".  I haven't fully traced this down yet, and the
zt_init_tone_state may indicate that one must wait for a new call to arrive
first, but in every case I have seen recently of this being accidentally
run on a production system, it has Oopsed.

I can file a separate bug report about this with further details, if
desired.     I would have to set up a lab environment with some fake calls
to test further.  I asked on IRC but it sounded like people weren't
interesting in fixing these bugs because this code is (theoretically) only
supposed to be run once during initialization. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-02-08 12:52  sim            Note Added: 0076217                          
======================================================================