Attention is currently required from: pespin, msuraev. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/28892 )

Change subject: BSSMAP: make sure we don't try to reset non-existent entity ......................................................................

Patch Set 2: Code-Review-1

(3 comments)

Patchset:

PS2: in OS#5551 i explain why this fix seems to be not needed. If there is ever a situation where bssmap_reset == NULL, we need to find that and fix it.

I currently don't see how that is possible at all. There is not even uncertainty, race or async things going on, it is simply not possible.

File src/osmo-bsc/bsc_vty.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/28892/comment/e679b15c_f951f808 PS2, Line 3393: if (!msc->a.bssmap_reset) { Wording confusion:

- this is not about "Resetting the BSSMAP interface", it is about sending a BSSMAP Reset message to the peer.

- this is not about an unallocated MSC.

If the MSC is not allocated, above 'if (!msc)' triggers.

If bssmap_reset is NULL, then the RESET message handling FSM instance has not been initialized / already torn down.

The code below is about sending a BSSMAP RESET message, so the log should say something like

"Unable to send BSSMAP RESET message, bssmap_reset FSM not allocated"

But did you actually face a situation like this? Seems unlikely to happen.

File src/osmo-bsc/bssmap_reset.c:

https://gerrit.osmocom.org/c/osmo-bsc/+/28892/comment/ef077194_f2e3c53d PS2, Line 249: LOGP(DMSC, LOGL_ERROR, "Attempt to reset non-existent BSSMAP\n"); No caller should call this function with a NULL argument. Otherwise we'd need to add such NULL checks to all of the API functions everywhere.

If it is really plausible, then:

Wording confusion: rather "Unable to send BSSMAP RESET message, no FSM instance present"