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

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Tue Aug 13 20:22:55 UTC 2019


pespin has submitted this change and it was merged. ( https://gerrit.osmocom.org/c/osmo-sgsn/+/15188 )

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(-)

Approvals:
  lynxis lazus: Looks good to me, approved
  Jenkins Builder: Verified



diff --git a/src/gprs/gprs_sgsn.c b/src/gprs/gprs_sgsn.c
index 8f1e54a..eb04846 100644
--- a/src/gprs/gprs_sgsn.c
+++ b/src/gprs/gprs_sgsn.c
@@ -313,7 +313,6 @@
 void sgsn_mm_ctx_cleanup_free(struct sgsn_mm_ctx *mm)
 {
 	struct gprs_llc_llme *llme = NULL;
-	uint32_t tlli = mm->gb.tlli;
 	struct sgsn_pdp_ctx *pdp, *pdp2;
 	struct sgsn_signal_data sig_data;
 
@@ -362,7 +361,6 @@
 
 	if (llme) {
 		/* TLLI unassignment, must be called after sgsn_mm_ctx_free */
-		OSMO_ASSERT(llme->tlli == tlli);
 		if (gprs_llgmm_unassign(llme) < 0)
 			LOGMMCTXP(LOGL_ERROR, mm, "gprs_llgmm_unassign failed, llme not freed!\n");
 	}

-- 
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-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190813/30d1145a/attachment.htm>


More information about the gerrit-log mailing list