commit b9fede74ef0b9ac98acbe64a95e704cfbffac342
author Pau Espin Pedrol <pespin@sysmocom.de> Tue Oct 12 19:52:02 2021 +0200
committer Pau Espin Pedrol <pespin@sysmocom.de> Tue Oct 12 20:07:19 2021 +0200
tree 70e8f4c1eda66be91354cce2df5f769a186ae84a
parent ffa2918bc55c25e3aa3e514e4bd6a22856b61d0e

tbf: Avoid keeping poll nodes in pdch_ulc of temporary control_ts used during PACCH assignment

When MS sends us the Packet Resource Request as RRBP from final UL ACK/NACK, we create a new TBF
with a different set of allocated TS. However, we must send the Pkt UL Assignment with information
of the new TBF using that same TS where we receive the Packet Resource Request, which happens to
be the control TS of the previous/old TBF. The original control TS of the new TBF is kept in
tbf->first_common_ts.

Hence the code does gprs_rlcmac_pdch::rcv_resource_request():
"""
ul_tbf->control_ts = ts_no;
"""

And later, when we receive a CTRL ACK answering the Pkt UL Assigment, we change the control TS of
the new TBF back to the new one, by calling tbf_assign_control_ts(), which basically does:
"""
tbf->control_ts = tbf->first_common_ts;
"""

So, for instance we have a TBF which was allocated with tbf->control_ts=4 and hence is only attached
to PDCH 4 (tbf->pdch[]), but for which is temporarily applied tbf->control_ts=7.  Hence, when a poll
is requested, it is done in control_ts, aka 7, which is not in the array of attached PDCH.

The problem is of course if we never reach the point where the final control_ts is set, due to never
receiving the CTRL ACK. If the TBF is freed (due to timer X2001) before receiving the CTRL ACK and
hence tbf_assign_control_ts() is called, a crash may occur, because potentially a poll for the TBF is
left in TS 7 because it's not a PDCH attached to the TBF and hence poll
entries on that TS are not released, hence keeping a pointer to the
freed TBF.

Related: SYS#5647
Change-Id: I0c49f2695e0d932d956c01976c9458eebee63cd4