mirror of https://github.com/asterisk/asterisk
The scenario where a channel still has an associated datastore we cannot unload since there is a function pointer to the destroy and fixup functions in play. Thus increase the module ref count whenever we allocate a datastore, and decrease it during destroy. In order to tighten the race that still exists in spite of this (below) add some extra failure cases to prevent allocations in these cases. Race: If module ref is zero, an LOCK or TRYLOCK is invoked (near) simultaneously on a channel that has NOT PREVIOUSLY taken a lock, and if in such a case the datastore is created *prior* to unloading being set to true (first step in module unload) then it's possible that the module will unload with the destructor being called (and segfault) post the module being unloaded. The module will however wait for such locks to release prior to unloading. If post that we can recheck the module ref before returning the we can (in theory, I think) eliminate the last of the race. This race is mostly theoretical in nature. Change-Id: I21a514a0b56755c578a687f4867eacb8b59e23cf Signed-off-by: Jaco Kroon <jaco@uls.co.za>18.5
parent
6f303335d3
commit
6b67821098
Loading…
Reference in new issue