Change in osmo-bsc[master]: Fix ts_for_each_lchan iteration for dynamic TS in process of being PD...

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/.

Pau Espin Pedrol gerrit-no-reply at lists.osmocom.org
Tue Nov 27 19:19:42 UTC 2018


Pau Espin Pedrol has uploaded this change for review. ( https://gerrit.osmocom.org/11957


Change subject: Fix ts_for_each_lchan iteration for dynamic TS in process of being PDCH deactivated
......................................................................

Fix ts_for_each_lchan iteration for dynamic TS in process of being PDCH deactivated

In general PDCH channels are not handled as lchans in BTS (lchan_fsm.c),
and so when a TS is in ts->pchan_is=GSM_PCHAN_PDCH, no lchan slot is
being used.

However, during Dynamic TS PDCH Deactivation being in progress (state
WAIT_PDCH_DEACT in timeslot_fsm.c), ts->pchan_is =GSM_PCHAN_PDCH, but
an lchan slot of that TS is actually already being used by a TCH lchan:
it's the one who initiated the deactivate in order to be able to use the TS.

While being in WAIT_PDCH_DEACT state and receiving a PDCH DEACT NACK,
ts_fsm_error() was called in order to kill the TS and it was expected
that it would kill any lchan using it (or willing to start using it). In
order to do that, it calls ts_lchans_dispatch() which in turns iterates
over all lchans attached to the TS using ts_for_each_lchan().

However, when the NACK arrived we still had ts->pchan_is=GSM_PCHAN_PDCH,
ts_for_each_lchan ends up calling
ts_as_pchan_for_each_lchan(GSM_PCHAN_PDCH), which in turns calls
pchan_subslots(GSM_PCHAN_PDCH) which returns 0, because we don't manage
lchans in that mode as explained in first paragraph. This means in this
case ts_for_each_lchan() is actually an empty loop while still any of
the TCH channels may be in use, and won't be advertised about the TS
entering in a broken state.

As a result, the lchan won't be released for a while, only after T23001
expires.

In ts_for_each_lchan(), as its name indicates, we want to iterate over
all lchans, and then if needed check if they are in use.

Other users of ts_for_each_lchan() have checks like
lchan_state_is(lchan, LCHAN_ST_UNUSED) or are fine about this
scenarios anyway.

Related: OS#3708
Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
---
M include/osmocom/bsc/gsm_data.h
M src/osmo-bsc/timeslot_fsm.c
2 files changed, 5 insertions(+), 3 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/57/11957/1

diff --git a/include/osmocom/bsc/gsm_data.h b/include/osmocom/bsc/gsm_data.h
index 15158cd..d4318ad 100644
--- a/include/osmocom/bsc/gsm_data.h
+++ b/include/osmocom/bsc/gsm_data.h
@@ -461,8 +461,10 @@
  * ts_for_each_lchan(lchan, ts) {
  * 	LOGPLCHAN(DMAIN, LOGL_DEBUG, "hello world\n");
  * }
- * Iterate only those lchans that have an FSM allocated. */
-#define ts_for_each_lchan(lchan, ts) ts_as_pchan_for_each_lchan(lchan, ts, (ts)->pchan_is)
+ * Iterate only those lchans that have an FSM allocated.
+ * ts->pchan_on_init containing dynamic TS type is passed in order to calculate
+ * max amount of lchans available in any of the possible modes. */
+#define ts_for_each_lchan(lchan, ts) ts_as_pchan_for_each_lchan(lchan, ts, (ts)->pchan_on_init)
 
 /* Same as ts_for_each_lchan() but with an explicit pchan kind (GSM_PCHAN_* constant).
  * Iterate only those lchans that have an FSM allocated. */
diff --git a/src/osmo-bsc/timeslot_fsm.c b/src/osmo-bsc/timeslot_fsm.c
index 659c645..f55633f 100644
--- a/src/osmo-bsc/timeslot_fsm.c
+++ b/src/osmo-bsc/timeslot_fsm.c
@@ -550,7 +550,7 @@
 	ts->pdch_act_allowed = true;
 
 	/* For static TS, check validity. For dyn TS, figure out which PCHAN this should become. */
-	ts_as_pchan_for_each_lchan(lchan, ts, ts->pchan_on_init) {
+	ts_for_each_lchan(lchan, ts) {
 		if (lchan_state_is(lchan, LCHAN_ST_UNUSED))
 			continue;
 

-- 
To view, visit https://gerrit.osmocom.org/11957
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I9cedb77d6578597f1febab36c54b2ee427c7a4a2
Gerrit-Change-Number: 11957
Gerrit-PatchSet: 1
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20181127/6819d11d/attachment.htm>


More information about the gerrit-log mailing list