]> git.ipfire.org Git - thirdparty/asterisk.git/commit
func_lock: Prevent module unloading in-use module.
authorJaco Kroon <jaco@uls.co.za>
Sat, 22 May 2021 12:53:43 +0000 (14:53 +0200)
committerFriendly Automation <jenkins2@gerrit.asterisk.org>
Fri, 11 Jun 2021 18:24:56 +0000 (13:24 -0500)
commit19a8383a1fffc137e6ceb4faae9c3c2f3a9dd1a7
treee4f09ced1987a9959fe0eecbdd67af030188f24f
parente8875d5ca141e45a7d8cb27b492ffebc42a275e0
func_lock: Prevent module unloading in-use module.

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>
funcs/func_lock.c