maki/openairinterface5g
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

hack in RLC AM to avoid a race

Browse Source 
Here is the problem:
    UE comes. SRB2 is configured via message to RRC.
    At some point the RLC AM is created but not configured yet.
    At this moment (I think) MAC calls mac_rlc_status_ind
    which calls this function. But the init was not finished yet
    and we have a crash below when testing mem_block != NULL.

The "solution" is to test if rlc->input_sdus is NULL.
This is a very dirty hack. I would say the solution
is to use proper locking mechanism because RLC is used
by two threads: PHY/MAC on one hand and RRC on another
hand (I think).
This commit is contained in:
Cedric Roux
2017-01-19 09:57:43 +01:00
parent 05d02c43ec
commit 38b387794e
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openair2/LAYER2/RLC/AM_v9.3.0/rlc_am.c
+9
View File
@@ -557,6 +557,15 @@ rlc_am_mac_status_indication (
status_resp.head_sdu_is_segmented = 0;
status_resp.rlc_info.rlc_protocol_state = rlc->protocol_state;
/* TODO: remove this hack. Problem is: there is a race.
* UE comes. SRB2 is configured via message to RRC.
* At some point the RLC AM is created but not configured yet.
* At this moment (I think) MAC calls mac_rlc_status_ind
* which calls this function. But the init was not finished yet
* and we have a crash below when testing mem_block != NULL.
*/
if (rlc->input_sdus == NULL) return status_resp;
if (rlc->last_frame_status_indication != ctxt_pP->frame) {
rlc_am_check_timer_poll_retransmit(ctxt_pP, rlc);
rlc_am_check_timer_reordering(ctxt_pP, rlc);