commit | 1f9cc018618e7d1e9a7a37e1ef08e059a4e02e87 | [log] [tgz] |
---|---|---|
author | Neels Hofmeyr <neels@hofmeyr.de> | Sun Mar 24 05:56:21 2019 +0100 |
committer | Neels Hofmeyr <nhofmeyr@sysmocom.de> | Thu Apr 11 05:36:36 2019 +0000 |
tree | c8e35f999c2bba99330bc4ffe60f9d858aaf805a | |
parent | 3b414a4adc8687af1a32f36fc1553bc65fb6b348 [diff] |
fsm: support graceful osmo_fsm_inst_term() cascades Add global flag osmo_fsm_term_safely() -- if set to true, enable the following behavior: Detect osmo_fsm_inst_term() occuring within osmo_fsm_inst_term(): - collect deallocations until the outermost osmo_fsm_inst_term() is done. - call osmo_fsm_inst_free() *after* dispatching the parent event. If a struct osmo_fsm_inst enters osmo_fsm_inst_term() while another is already within osmo_fsm_inst_term(), do not directly deallocate it, but talloc-reparent it to a separate talloc context, to be deallocated with the outermost FSM inst. The effect is that all osmo_fsm_inst freed within an osmo_fsm_inst_term() cascade will stay allocated until all osmo_fsm_inst_term() are complete and all of them will be deallocated at the same time. Mark the deferred deallocation state as __thread in an attempt to make cascaded deallocation handling threadsafe. Keep the enable/disable flag separate, so that it is global and not per-thread. The feature is showcased by fsm_dealloc_test.c: with this feature, all of those wild deallocation scenarios succeed. Make fsm_dealloc_test a normal regression test in testsuite.at. Rationale: It is difficult to gracefully handle deallocations of groups of FSM instances that reference each other. As soon as one child dispatching a cleanup event causes its parent to deallocate before fsm.c was ready for it, deallocation will hit a use-after-free. Before this patch, by using parent_term events and distinct "terminating" FSM states, parent/child FSMs can be taught to wait for all children to deallocate before deallocating the parent. But as soon as a non-child / non-parent FSM instance is involved, or actually any other cleanup() action that triggers parent FSMs or parent talloc contexts to become unused, it is near impossible to think of all possible deallocation events ricocheting, and to avoid running into freeing FSM instances that were still in the middle of osmo_fsm_inst_term(), or FSM instances to enter osmo_fsm_inst_term() more than once. This patch makes deallocation of "all possible" setups of complex cross referencing FSM instances easy to handle correctly, without running into use-after-free or double free situations, and, notably, without changing calling code. Change-Id: I8eda67540a1cd444491beb7856b9fcd0a3143b18
This repository contains a set of C-language libraries that form the core infrastructure of many Osmocom Open Source Mobile Communications projects.
Historically, a lot of this code was developed as part of the OpenBSC project, but which are of a more generic nature and thus useful to (at least) other programs that we develop in the sphere of Free Software / Open Source mobile communications.
There is no clear scope of it. We simply move all shared code between the various Osmocom projects in this library to avoid code duplication.
The libosmcoore.git repository build multiple libraries:
The official homepage of the project is https://osmocom.org/projects/libosmocore/wiki/Libosmocore
You can clone from the official libosmocore.git repository using
git clone git://git.osmocom.org/libosmocore.git
There is a cgit interface at http://git.osmocom.org/libosmocore/
Doxygen-generated API documentation is generated during the build process, but also available online for each of the sub-libraries at http://ftp.osmocom.org/api/latest/libosmocore/
Discussions related to libosmocore are happening on the openbsc@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/openbsc for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for libosmocore can be seen at https://gerrit.osmocom.org/#/q/project:libosmocore+status:open