Attention is currently required from: pespin, msuraev.

Patch set 2:Code-Review -1

3 comments:

Patchset:
- Patch Set #2:
  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:
- Patch Set #2, 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:
- Patch Set #2, 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"

To view, visit change 28892. To unsubscribe, or for help writing mail filters, visit settings.