summaryrefslogtreecommitdiffstats
path: root/src/fsm.c
Commit message (Collapse)AuthorAgeFilesLines
* fsm: refuse state chg and events after termNeels Hofmeyr2019-10-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refuse state changes and event dispatch for FSM instances that are already terminating. It is assumed that refusing state changes and events after FSM termination is seen as the sane expected behavior, hence this change in behavior is merged without being configurable. There is no fallout in current Osmocom code trees. fsm_dealloc_test needs a changed expected output, since it is explicitly creating complex FSM structures that terminate. Currently no other C test in Osmocom code needs adjusting. Rationale: Where multiple FSM instances are collaborating (like in osmo-bsc or osmo-msc), a terminating FSM instance often causes events to be dispatched back to itself, or causes state changes in FSM instances that are already terminating. That is hard to avoid, since each FSM instance could be a cause of failure, and wants to notify all the others of that, which in turn often choose to terminate. Another use case: any function that dispatches events or state changes to more than one FSM instance must be sure that after the first event dispatch, the second FSM instance is in fact still allocated. Furthermore, if the second FSM instance *has* terminated from the first dispatch, this often means that no more actions should be taken. That could be done by an explicit check for fsm->proc.terminating, but a more general solution is to do this check internally in fsm.c. In practice, I need this to avoid a crash in libosmo-mgcp-client, when an on_success() event dispatch causes the MGCP endpoint FSM to deallocate. The earlier dealloc-in-main-loop patch fixed part of it, but not all. Change-Id: Ia81a0892f710db86bd977462730b69f0dcc78f8c
* add osmo_fsm_set_dealloc_ctx(), to help with use-after-freeNeels Hofmeyr2019-10-291-9/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a simpler and more general solution to the problem so far solved by osmo_fsm_term_safely(true). This extends use-after-free fixes to arbitrary functions, not only FSM instances during termination. The aim is to defer talloc_free() until back in the main loop. Rationale: I discovered an osmo-msc use-after-free crash from an invalid message, caused by this pattern: void event_action() { osmo_fsm_inst_dispatch(foo, FOO_EVENT, NULL); osmo_fsm_inst_dispatch(bar, BAR_EVENT, NULL); } Usually, FOO_EVENT takes successful action, and afterwards we also notify bar. However, in this particular case, FOO_EVENT caused failure, and the immediate error handling directly terminated and deallocated bar. In such a case, dispatching BAR_EVENT causes a use-after-free; this constituted a DoS vector just from sending messages that cause *any* failure during the first event dispatch. Instead, when this is enabled, we do not deallocate 'foo' until event_action() has returned back to the main loop. Test: duplicate fsm_dealloc_test.c using this, and print the number of items deallocated in each test loop, to ensure the feature works. We also verify that the deallocation safety works simply by fsm_dealloc_test.c not crashing. We should probably follow up by refusing event dispatch and state transitions for FSM instances that are terminating or already terminated: see I0adc13a1a998e953b6c850efa2761350dd07e03a. Change-Id: Ief4dba9ea587c9b4aea69993e965fbb20fb80e78
* avoid gcc format error on embedded buildsHarald Welte2019-07-311-1/+1
| | | | | | | | | | | | | when using gcc 8.3.0 on Debian unstable and doing an embedded build, I'm getting the following error: > fsm.c:621:40: error: format '%ld' expects argument of type > 'long int', but argument 6 has type 'time_t {aka long long int}' > [-Werror=format=] Let's avoid that... Change-Id: I92fb9b08def8475739f0dc6316de43b166f48ac3
* Revert "fsm.c: Print error message for FSM with allstate_action but no events"Vadim Yanitskiy2019-06-161-11/+0
| | | | | | | | | This reverts commit b3f94eb39e19366c3458643ee329a73155d46ff8, that unfortunately breaks some projects which call osmo_fsm_register() on DSO load (i.e. using __attribute__((constructor))) before the logging is initialized. Change-Id: Idc6fcce7e946c23d48589b920e309d60aa7b6645
* fsm.c: Print error message for FSM with allstate_action but no eventsHarald Welte2019-06-151-0/+11
| | | | | | | | | | As suggested by Vadim while reviewing a related fix for ipa_keepalive.c in libosmo-abis (see https://gerrit.osmocom.org/#/c/libosmo-abis/+/13540/), it makes sense to print an error message if anyone registers a FSM that specifies an allstate_action callback but at the same time no events that would ever end up in that callback. Change-Id: I9e73f7363ab15a00843e3f0d1e5776f4be7ebc46
* fsm: Reduce amount of copy+pasted LOGPFSMSRC() statementsHarald Welte2019-06-051-17/+15
| | | | | | | | Instead of copy+pasting the same LOGPFSMSRC("State change to " ...) with slightly different trailer depending on the FSM timer, let's first snprintf() to a stack variable and then have a single log statement. Change-Id: I49528c4ca1fa11aef09c2092615dccca450b847c
* fsm: Allow millisecond granularity in osmo_fsm built-in timerHarald Welte2019-06-051-23/+31
| | | | | | | | | | | | | | | | | | | | | | | So far, the public API of osmo_fsm only allowed integral seconds as timeout. Let's change that to milli-seconds in order to cover more use cases. This introduces * osmo_fsm_inst_state_chg_ms() * osmo_fsm_inst_state_chg_keep_or_start_timer_ms() Which both work exactly like their previous counterparts without the _ms suffix - the only difference being that the timeout parameter is specified in milli-seconds, not in seconds. The value range for an unsigned long in milli-seconds even on a 32bit platform extends to about 48 days. This patch also removes the documentation notice about limiting the maximum value to 0x7fffffff due to time_t signed-ness. We don't use time_t but unsigned long. Change-Id: I35b330e460e80bb67376c77e997e464439ac5397
* make all library-internal static buffers thread-localHarald Welte2019-06-041-2/+2
| | | | | | | | | | | | | | | We have a number of library-internal static global buffers which are mainly used for various stringification functions. This worked as all of the related Osmocom programs were strictly single-threaded. Let's make those buffers at least thread-local. This way every thread gets their own set of buffers, and it's safe for multiple threads to execute the same functions once. They're of course still not re-entrant. If you need re-entrancy, you will need to use the _c() or _buf() suffix version of those functions and work with your own (stack or heap) buffers. Change-Id: I50eb2436a7c1261d79a9d2955584dce92780ca07
* fix typo in FSM descriptionKévin Redon2019-05-091-4/+4
| | | | Change-Id: I3559e9c0769b708cee0d1b221b60960c62f15bd4
* add identifier sanitation for setting FSM instance idsNeels Hofmeyr2019-04-121-0/+29
| | | | | | | | | | | | | | | | | | | | We often compose FSM instance IDs from context information, for example placing an MSISDN string or IP:port information in the FSM instance id, using osmo_fsm_inst_update_id_f(). This fails if any characters are contained that don't pass osmo_identifier_valid(). Hence it is the task of the caller to make sure only characters allowed in an FSM id are applied. Provide API to trivially allow this by replacing illegal chars: - osmo_identifier_sanitize_buf(), with access to the same set of illegal characters defined in utils.c, - osmo_fsm_inst_update_id_f_sanitize() implicitly replaces non-identifier chars. This makes it easy to add strings like '192.168.0.1:2342' or '+4987654321' to an FSM instance id, without adding string mangling to each place that sets an id; e.g. replacing with '-' to yield '192-168-0-1:2342' or '-4987654321'. Change-Id: Ia40a6f3b2243c95fe428a080b938e11d8ab771a7
* fsm: support graceful osmo_fsm_inst_term() cascadesNeels Hofmeyr2019-04-111-6/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* fsm: add flag to ensure osmo_fsm_inst_term() happens only onceNeels Hofmeyr2019-04-111-0/+6
| | | | | | | | | | | To prevent re-entering osmo_fsm_inst_term() twice for the same osmo_fsm_inst, add flag osmo_fsm_inst.proc.terminating. osmo_fsm_inst_term() sets this to true, or exits if it already is true. Update fsm_dealloc_test.err for illustration. It is not relevant for unit testing yet, just showing the difference. Change-Id: I0c02d76a86f90c49e0eae2f85db64704c96a7674
* Doxygen: fix incorrect / missing parameter descriptionVadim Yanitskiy2019-03-251-1/+1
| | | | Change-Id: Ibc63a5d4442a192efab8b5b30e0beb3545642ecc
* fsm: add osmo_fsm_inst_state_chg_keep_or_start_timer()Neels Hofmeyr2019-03-071-6/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | During FSM design for osmo-msc, I noticed that the current behavior that keep_timer=true doesn't guarantee a running timer can make FSM design a bit complex, especially when using osmo_tdef for timeout definitions. A desirable keep_timer=true behavior is one that keeps the previous timer running, but starts a timer if no timer is running yet. The simplest example is: a given state repeatedly transitions back to itself, but wants to set a timeout only on first entering, avoiding to restart the timeout on re-entering. Another example is a repeated transition between two or more states, where the first time we enter this group a timeout should start, but it should not restart from scratch on every transition. When using osmo_tdef timeout definitions for this, so far separate meaningless states have to be introduced that merely set a fixed timeout. To simplify, add osmo_fsm_inst_state_chg_keep_or_start_timer(), and use this in osmo_tdef_fsm_inst_state_chg() when both keep_timer == true *and* T != 0. In tdef_test.ok, the changes show that on first entering state L, the previous T=1 is now kept with a large remaining timeout. When entering state L from O, where no timer was running, this time L's T123 is started. Change-Id: Id647511a4b18e0c4de0e66fb1f35dc9adb9177db
* represent negative T-timers as Osmocom-specific X-timersNeels Hofmeyr2019-03-061-9/+15
| | | | | | | | | | | | | | | | | | | | fi->T values are int, i.e. can be negative. Do not log them as unsigned, but define a distinct timer class "Xnnnn" for negative T values: i.e. for T == -1, print "Timeout of X1" instead of "Timeout of T4294967295". The negative T timer number space is useful to distinguish freely invented timers from proper 3GPP defined T numbers. So far I was using numbers like T993210 or T9999 for invented T, but X1, X2 etc. is a better solution. This way we can make sure to not accidentally define an invented timer number that actually collides with a proper 3GPP specified timer number that the author was not aware of at the time of writing. Add OSMO_T_FMT and OSMO_T_FMT_ARGS() macros as standardized timer number print format. Use that in fsm.c, tdef_vty.c, and adjust vty tests accordingly. Mention the two timer classes in various API docs and VTY online-docs. Change-Id: I3a59457623da9309fbbda235fe18fadd1636bff6
* log: fsm: allow logging the timeout on state changeNeels Hofmeyr2019-02-261-2/+39
| | | | | | | | | | | | | | | | Add a flag that adds timeout info to osmo_fsm_inst state change logging. To not affect unit testing, make this an opt-in feature that is disabled by default -- mostly because osmo_fsm_inst_state_chg_keep_timer() will produce non-deterministic logging depending on timing (logs remaining time). Unit tests that don't verify log output and those that use fake time may also enable this feature. Do so in fsm_test.c. The idea is that in due course we will add osmo_fsm_log_timeouts(true) calls to all of our production applications' main() initialization. Change-Id: I089b81021a1a4ada1205261470da032b82d57872
* add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr2019-02-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
* osmo_fsm_inst_state_chg(): clamp timeout_secs to <= ~68 yearsNeels Hofmeyr2019-01-311-1/+13
| | | | | | | | | | | | | | | | | | | | During testing of the upcoming tdef API, it became apparent that passing very large timeout values to osmo_fsm_inst_state_chg() wraps back in the number range, and might actually result in effectively very short timeouts instead. Since time_t's range is not well defined across platforms, use a reasonable maximum value of signed 32 bit integer. Hence this will be safe at least on systems with an int32_t for struct timeval.tv_sec and larger. Clamp the osmo_fsm_inst_state_chg() timeout_secs argument to a maximum of 0x7fffffff, which amounts to just above 68 years: float(0x7fffffff) / (60. * 60 * 24 * 365.25) = 68.04965038532715 (In upcoming patch Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5, this can be verified to work by invoking tdef_test manually with a cmdline argument passed to enable the range check.) Change-Id: I35ec4654467b1d6040c8aa215049766089e5e64a
* osmo_fsm_inst_state_chg(): set T also for zero timeoutNeels Hofmeyr2019-01-291-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, if timeout_secs == 0 was passed to osmo_fsm_inst_state_chg(), the previous T value remained set in the osmo_fsm_inst->T. For example: osmo_fsm_inst_state_chg(fi, ST_X, 23, 42); // timer == 23 seconds; fi->T == 42 osmo_fsm_inst_state_chg(fi, ST_Y, 0, 0); // no timer; fi->T == 42! Instead, always set to the T value passed to osmo_fsm_inst_state_chg(). Adjust osmo_fsm_inst_state_chg() API doc; need to rephrase to accurately describe the otherwise unchanged behaviour independently from T. Verify in fsm_test.c. Rationale: it is confusing to have a T number remaining from some past state, especially since the user explicitly passed a T number to osmo_fsm_inst_state_chg(). (Usually we are passing timeout_secs=0, T=0). I first thought this behavior was introduced with osmo_fsm_inst_state_chg_keep_timer(), but in fact osmo_fsm_inst_state_chg() behaved this way from the start. This shows up in the C test for the upcoming tdef API, where the test result printout was showing some past T value sticking around after FSM state transitions. After this patch, there will be no such confusion. Change-Id: I65c7c262674a1bc5f37faeca6aa0320ab0174f3c
* fsm: fix apidoc of osmo_fsm_state_name()Philipp Maier2018-11-161-1/+1
| | | | | | | The api documentation of osmo_fsm_state_name() refers to an FSM instance, but it really means the state of an FSM. Change-Id: I88ddd6048426d380c49170e66f57b3843398c046
* add osmo_fsm_inst_state_chg_keep_timer()Neels Hofmeyr2018-05-311-30/+64
| | | | Change-Id: I3c0e53b846b2208bd201ace99777f2286ea39ae8
* fsm: guard action callbackPhilipp Maier2018-05-151-1/+3
| | | | | | | | | | | The FSM allows to set individual action callback functions for each state but it does not allow to leave the action callback pointer unpopulated. However, there are cornercases where having no callback function is desirable. - Check if action callback is popolated before executing it. Change-Id: I36d221c973d3890721ef1d376fb9be82c4311378
* add osmo_fsm_inst_update_id_f()Neels Hofmeyr2018-04-091-22/+45
| | | | | | | | | | | | | | | | In the osmo-msc, I would like to set the subscr conn FSM identifier by a string format, to include the type of Complete Layer 3 that is taking place. I could each time talloc a string and free it again. This API is more convenient. From osmo_fsm_inst_update_id(), call osmo_fsm_inst_update_id_f() with "%s" (or pass NULL). Put the name updating into separate static update_name() function to clarify. Adjust the error message for erratic ID: don't say "allocate", it might be from an update. Adjust test expectation. Change-Id: I76743a7642f2449fd33350691ac8ebbf4400371d
* cosmetic: osmo_fsm_inst_update_id(): don't log "allocate"Neels Hofmeyr2018-04-091-2/+3
| | | | | | | | | On erratic id in osmo_fsm_inst_update_id(), don't say "Attempting to allocate FSM instance". Escape the invalid id using osmo_quote_str(). Change-Id: I770fc460de21faa42b403f694e853e8da01c4bef
* fsm: id: properly set name in case of NULL idNeels Hofmeyr2018-04-091-5/+3
| | | | | | | | | | Since alloc relies on osmo_fsm_inst_update_id() to set the name, never skip that. In osmo_fsm_inst_alloc(), we allow passing a NULL id, and in osmo_fsm_inst_update_id(), we set the name without id if id is NULL. Change-Id: I6d6b09a811b82770818f19b189a57d9fc4a8133b
* osmo_fsm_inst_find_by_name(): guard against strcmp(NULL)Neels Hofmeyr2018-04-091-0/+5
| | | | | | | | | | | | | | | | | | strcmp() *must not* be passed NULL pointers, or we hit: ../../../src/libosmocore/src/fsm.c:123:8: runtime error: null pointer passed as argument 2, which is declared to never be null ASAN:DEADLYSIGNAL (Or, alternatively, a segfault.) If any of the search string or an FSM instance's name string should be NULL, simply never match. Technically, an FSM should never have a NULL name, but a current bug actually allows this (pass NULL id to alloc), which will be addressed by an upcoming patch. To test for it, we need to first make sure this here doesn't segfault. Change-Id: I2e5f82c06d1a4727bd93e955366e3b62b2df1b32
* fsm: Update the name as well if the id is updated and accept NULLDaniel Willmann2018-03-191-14/+22
| | | | | | | | | If the name stays the same the log messages will still log with the old id. Since we can now change the id we need to update the name as well. NULL as id was allowed before so we should allow that as well. Change-Id: I6b01eb10b8a05fee3e4a5cdefdcf3ce9f79545b4
* print BIG FAT ERROR message if osmo_fsm lacks event namesStefan Sperling2018-02-261-0/+2
| | | | | | | | | | | | Event names are displayed in VTY commands so all FSM should have them. Print an error message if an FSM is registered without event names. We could also return an error code, however at present no caller checks the return value of osmo_fsm_register() so this would be pointless. Add event names to the test FSM and update expected output accordingly. Change-Id: I08b100d62b5c50bf025ef87d31ea39072539cf37 Related: OS#3008
* fsm: allow graceful exit on FSM terminationPhilipp Maier2018-02-191-2/+13
| | | | | | | | | | | | | | | | The function _osmo_fsm_inst_term() terminates all child FSMs befor it calls fi->fsm_cleanup(). This prevents the cleanup callback to perform last actions on the child FSMs (e.g. osmo_fsm_inst_unlink_parent()). - Since moving the cleanup callack to the beginning of the function would alter the termination behavior and possibly cause malfunction in already existing implementation that use OSMO fsm, a new optional callback that is called immediately at the beginning of the terminatopn process is added. Change-Id: I0fdda9fe994753f975a658c0f3fb3615949cc8bb Closes: OS#2915
* fsm: Add a function to change the FSM instance ID laterDaniel Willmann2018-02-151-6/+25
| | | | | | | Sometimes we want to create an FSM instance before we know its name. In that case we should be able to update the id later. Change-Id: Ic216e5b11d4440f8e106a297714f4f06c1152945
* Revert "fsm: do not terminate child FSMs early"Harald Welte2018-02-091-4/+3
| | | | | | | | This reverts commit 5ec91980ac2224aa1e9bf070a0e382d0d8c2b729. More or less like I expected, it creates fall-out. osmo-msc master builds are failing, as are the open build service builds. The patch has therefor *not* been sufficiently tested. Change-Id: I8d961d7bbd91b6a8d7691f24cb67720c3d001c7e
* fsm: do not terminate child FSMs earlyPhilipp Maier2018-02-091-3/+4
| | | | | | | | | | | | The function _osmo_fsm_inst_term() terminates all child FSMs befor it calls fi->fsm_cleanup(). This prevnts the cleanup callback to perform last actions on the child FSMs (e.g. osmo_fsm_inst_unlink_parent()). move the function call to _osmo_fsm_inst_term_children() below the call to fi->fsm->cleanup(). Change-Id: Ie89d435417306c6bf897274eabc3ed0a46485c26
* fsm: add functions for unlinking and changing parentsPhilipp Maier2018-01-241-3/+34
| | | | | | | | | | | | | | At the moment it is not possible to unlink a child from from its parent, nor is it possible to assign a new parent to a child FSM. - osmo_fsm_inst_unlink_parent(): Make it possible to unlink childs from a parent. - osmo_fsm_inst_change_parent(): Make it possible to change the parent of a child. Change-Id: I6d18cbd4ada903cf3720b3ad2a89fc643085beef
* fsm: fix double llist_del in osmo_fsm_inst_term()Philipp Maier2018-01-171-2/+3
| | | | | | | | | | | llist_del(&fi->proc.child) is executed always, regardless whether a parent is configured or not. This may lead into a double llist_del when the child has been previously unlinked. - check if fi->proc.parent is set, and only then execute llist_del(&fi->proc.child); Change-Id: I4b33d508c8a11b72fbf30125088a882894d9e6ac
* fsm_tmr_cb: don't set T=0, the fi may no longer existNeels Hofmeyr2017-11-251-4/+5
| | | | | | | | | | | | | | | | | | | | | When calling the timer_cb, that may have effected an fi termination and deallocation, e.g. from dispatching events and/or complex choices made. Current timer_cb implementations expect T to reflect the fired timer number, so we can't actually set T=0 before calling the timer_cb. Instead, never reset T to zero, let it always reflect the timer that last fired. When a new timer starts, T will be set to its new value. Adding a T arg to the timer_cb() would have been the cleanest solution, so that fi->T can be set to zero before dispatching the timer_cb. But since we've already rolled out this FSM API, we should stay backwards compatible. In the case where the timer returned 1 to request termination, we can assume that the fi still exists, but to be consistent, don't set T = 0 in that code path either. Change-Id: I18626b55a1491098b3ed602df1b331f08d25625a
* Fix/Update copyright notices; Add SPDX annotationHarald Welte2017-11-131-0/+2
| | | | | | | | Let's fix some erroneous/accidential references to wrong license, update copyright information where applicable and introduce a SPDX-License-Identifier to all files. Change-Id: I39af26c6aaaf5c926966391f6565fc5936be21af
* fsm: Enforce FSM and FSM instance names are valid osmocom identifiersHarald Welte