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

Change subject: hnb_context_release(): Make sure assigned conn is freed ......................................................................

Patch Set 1:

(4 comments)

Commit Message:

https://gerrit.osmocom.org/c/osmo-hnbgw/+/29336/comment/730bcf09_d8dce4dd PS1, Line 14: synchronous

isn't release always async, because it involves messages to/from remote?

I'm precisely saying synchronous here to explain this happen in the the release code path freeing the struct, not whatever protocol transaction, hence no other unexpected code paths like select loop are possible with the conn or the hnb_context not referencing one another.

File src/osmo-hnbgw/hnbgw.c:

https://gerrit.osmocom.org/c/osmo-hnbgw/+/29336/comment/af144b64_2812da9b PS1, Line 304: return 0; /* hnb_context is being freed, nothing do be done */

(i thought now it is just hnb->hnb_registered == false?) […]

the hnb pointer being null means the hnb_context related to this conn is being freed (hnb_closed_cb is called as a result of osmo_stream_srv_destroy() being called by hnb_context_release()).

So "hnb_context is being freed" is totally accurate here, it will be freed right straigh away when returning from this callback.

https://gerrit.osmocom.org/c/osmo-hnbgw/+/29336/comment/f981fe67_99a39152 PS1, Line 306: /* hnb: conn became broken, let's release the associated hnb.

maybe "conn closed on an active hnb_context" ... […]

hnb_registered=false is at the HNB layer through non having yet received an HNB-Register or after having received a HNB-De-Register message.

In here, the underlaying SCTP conn is being dropped, at which point we totally free the related hnb_context. So there's basically no hnb_context without conn, or conn without hnb_context.

https://gerrit.osmocom.org/c/osmo-hnbgw/+/29336/comment/db3ce9a1_c57cf6eb PS1, Line 374: to call

calling

Ack