Summary:	ASTERISK-15961: lack of locking in dahdi_request()
Reporter:	Guillaume Knispel (gknispel_proformatique)	Labels:
Date Opened:	2010-04-15 09:05:54	Date Closed:	2010-04-27 12:17:52
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_dahdi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	In dahdi_request(), iflist / ifend are acceded without any lock taken -- or alternatively pri->crvs / pri->crvend are. I don't know if/when those can be modified, especially regarding crv. For iflist/ifend, maybe reloads are concerned, and also pseudo channels, which I don't know what they are used for.
Comments:	By: Leif Madsen (lmadsen) 2010-04-15 10:14:18 I'm not quite sure what the issue is here. Is this something that is causing a problem, or is this just something you saw while doing some code review? By: Guillaume Knispel (gknispel_proformatique) 2010-04-15 11:22:08 Some code review. I don't think this could cause a real issue *for me* so I don't plan to try to trigger this potential issue on a test plateform. I leave it to others to evaluate if this could cause a real world issue. By: Leif Madsen (lmadsen) 2010-04-15 12:58:00 OK thanks! I'll put it in the queue. By: Richard Mudgett (rmudgett) 2010-04-27 12:16:53 The possibility of a problem resulting from this locking issue is very low.  The data structures are essentially static once they are setup.  The times they will change is when a channel is deleted by CLI command "dahdi destroy channel", the cloned pseudo channel is hung up, and dahdi destroys the channel from an event like a USB device disconnected. It is already fixed in trunk because there is only only one interface list to search. This is a case where fixing it is not really worth it in the 1.4 and 1.6.x branches. 1) It has not caused a problem. 2) It is a small window of opportunity while the needed list and lock is determined. 3) The data structures are essentially static.