commit cd325efae564384c74b4af6163303ddc81c7a3c1
author Neels Hofmeyr <neels@hofmeyr.de> Thu Nov 16 22:32:36 2017 +0100
committer Neels Hofmeyr <neels@hofmeyr.de> Mon Nov 20 17:22:42 2017 +0100
tree 91fd7a58c09d257546f188e8d9ce43933551adc2
parent 0128c78ffe25196f53fbbc0884a9c4587f493224

gprs_bssgp: bssgp_fc_in(): fix mem leak on queue overflow

All successful and all error code paths of bssgp_fc_in() free the msgb, except
the code path calling fc_enqueue() when the msg is dropped (due to queue being
full, or failure to allocate).

Callers could theoretically catch the -ENOSPC return value and discard the
msgb. However, in other code paths, a callback's return value is returned,
which is expected to free the msgb, so such callback would have to never return
-ENOSPC when it freed the msgb. Much simpler semantics would be to free the
msgb in every code path, no matter which kind of error occurred.

Who is currently calling bssgp_fc_in and how do they handle the return value?
- bssgp_fc_test.c ignores the return value (and hits a mem leak aka sanitizer
  build failure if the queue is full).
- fc_timer_cb() ignores the return value.
- bssgp_tx_dl_ud() returns the bssgp_fc_in() rc.
  - which is returned by a cascade of functions leading up to being returned,
    for example, by gprs_llgmm_reset(), which is usually called with ignored
    return code.
At this point it is already fairly clear that bssgp_fc_in() should always free
the msgb, since the callers don't seem to distinguish even between error or
success, let alone between -ENOSPC or other errors.

bssgp_fc_test: assert that no msgbs remain unfreed after the tests.
Adjust expected results.

Helps fix sanitizer build on debian 9.

Change-Id: I00c62a104baeaad6a85883c380259c469aebf0df