Attention is currently required from: fixeria, laforge, neels.

pespin has posted comments on this change by pespin. ( https://gerrit.osmocom.org/c/osmo-msc/+/40632?usp=email )

Change subject: ran_peer: Add specific API to free object ......................................................................

Patch Set 4:

(2 comments)

Commit Message:

https://gerrit.osmocom.org/c/osmo-msc/+/40632/comment/830de391_6c8d72e9?usp=... : PS2, Line 11: Swap the talloc tree parentship to have the fi be a child of the object, : which simplifies tear down triggered by FSM cleanup.

you may find that, but you have not convinced me yet. […]

I already described it. It's really difficult to figure out whether a given object is being freed because there's no specific API to free it. There's multiple of osmo_fsm_inst_term() calls all over the code and it's non trivial to figure out where an object is freed.

Do you mind telling me if I'm wrong and this object is being freed somewhere already? Because otherwise this change doesn't seem problematic in the PIVOTAL design.

File src/libmsc/ran_peer.c:

https://gerrit.osmocom.org/c/osmo-msc/+/40632/comment/c423c260_fc9b93ae?usp=... : PS4, Line 81: void ran_peer_free(struct ran_peer *rp)

AFAIR the idea is to instead call osmo_fsm_inst_term()

$ grep -r osmo_fsm_inst_term . | wc -l 37

And AFAICT none of those 37 calls is related to this object?