On Fri, Apr 22, 2016 at 03:47:29PM +0200, Holger Freyther wrote:
On 14 Apr 2016, at 15:21, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
openbsc/src/gprs/gprs_gmm.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/openbsc/src/gprs/gprs_gmm.c b/openbsc/src/gprs/gprs_gmm.c index 5f0a5fd..438e047 100644 --- a/openbsc/src/gprs/gprs_gmm.c +++ b/openbsc/src/gprs/gprs_gmm.c @@ -838,6 +838,10 @@ static int gsm48_rx_gmm_att_req(struct sgsn_mm_ctx *ctx, struct msgb *msg, int rc;
LOGMMCTXP(LOGL_INFO, ctx, "-> GMM ATTACH REQUEST ");
- if (!llme) {
same as with my other mail. The lower layer should create a llme on the fly. So please have a look at the coverity user interface to see _where_ the llme is NULL and then we can have a look at that issue.
There is, obviously, an explicit NULL on the sysmocom/iu branch, where no LLME is applicable.
openbsc/openbsc/src/gprs/gprs_gmm.c:2462: rc = gsm0408_rcv_gmm(mmctx, msg, NULL);
Coverity concerns itself about a
"Comparing llme to null implies that llme might be null."
so no actual NULL is reported. (though coverity could have reported above explicit NULL which I found manually)
Actually, the llme NULL check in gsm0408_rcv_gmm() is introduced in the sysmocom/iu branch along with mentioned explicit NULL:
1628 if (llme && !mmctx && 1629 gh->msg_type != GSM48_MT_GMM_ATTACH_REQ && 1630 gh->msg_type != GSM48_MT_GMM_RA_UPD_REQ) { 1631 LOGP(DMM, LOGL_NOTICE, "Cannot handle GMM for unknown MM CTX\n");
So my suggestion above to clean up llme only when it's not NULL does still make a lot of sense to me.
Since I'm not familiar with GRPS code, maybe Daniel could have a quick look? I'm having a déjà vu, didn't I write this before? Would be nice if I could stop banging my head against your wall now ;)
~Neels