Summary:ASTERISK-15961: lack of locking in dahdi_request()
Reporter:Guillaume Knispel (gknispel_proformatique)Labels:
Date Opened:2010-04-15 09:05:54Date Closed:2010-04-27 12:17:52
Versions:Frequency of
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.