Change in ...osmo-sgsn[master]: gprs_sgsn.c: Remove recently introduced assert

pespin gerrit-no-reply at lists.osmocom.org
Tue Aug 13 19:11:19 UTC 2019


Hello lynxis lazus, Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-sgsn/+/15188

to look at the new patch set (#2).

Change subject: gprs_sgsn.c: Remove recently introduced assert
......................................................................

gprs_sgsn.c: Remove recently introduced assert

Recent commit added an assert to make sure unexpected conditions were
happening in sgsn_mm_ctx_cleanup_free(). Old code was passing
mm->gb.tlli to gprs_llgmm_assign with "new tlli" being all-1's (aka
unassign mm->gb.tlli).
The commit changed the code to use gprs_llgmm_unassign, which uses
llme->tlli instead of mm->gb.tlli, and the assert was used to make sure
no behavior change occured with the commit.
It seems TTCN3 test TC_attach_auth_id_timeout triggers that assert, and
after closer debug it seems mm->gb.tlli == llme->old_tlli, which makes
sense since there's a mm->gb.tlli_new which is expected to be
llme->tlli.
When TLLI changes in GMM (Attach Request or RA Update), it is stored
into mm->gb.tlli_new and assigned on the LLC layer using gprs_llgm_assign(),
and upon completion signalling from MS, (after handling response to initial request)
it is assigned to mm->gb.tlli (and value kept in mm->gb.tlli_new).
So mm->gb.tlli and mm->gb.tlli_new usually contain the same value unless
a new TLLI is allocated, and during the span of
Request->Response->Complete it is kept different, the LLC layer having assigned
the value of mm->gb.tlli_new.
So, old code (before the commit adding the assert) was wrongly using
mm->gb.tlli instead of mm->gb.tlli_new at the moment of unassigning (but
not really problematic in practice since behavior is the same as long as
"old TLLI" value is not all-1's.
So we are fine and correct using gprs_llgm_unassign() (which passes llme->tlli
as "old TLLI") instead of what used to be done before.
In any case, the expected behavior is to free the llme object and get
rid of everything...

Fixes: 788863cda53298c24110d0fe0f8cd3309cdec747
Change-Id: I482acdbdf05ce0cb0a5804206672512854067f5b
---
M src/gprs/gprs_sgsn.c
1 file changed, 0 insertions(+), 2 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-sgsn refs/changes/88/15188/2
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-sgsn/+/15188
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-sgsn
Gerrit-Branch: master
Gerrit-Change-Id: I482acdbdf05ce0cb0a5804206672512854067f5b
Gerrit-Change-Number: 15188
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: lynxis lazus <lynxis at fe80.eu>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190813/11642dcc/attachment.html>


More information about the gerrit-log mailing list