More accurately, we changed the do/while infinite
loop to be an infinite for loop for the read command of
the socket. The socket file descriptor choice is more clear now.
More accurately, we changed the do/while infinite
loop to be an infinite for loop for the read command of
the socket. The socket file descriptor choice is more clear now.
Every if statement that includes a check for
the NFAPI_MODE that did not check for the new
PNF_STANDALONE_MODE now has been updated. Also
changed the tx_req and dl_config_req logs
when they are received at the OAI UE to be
info logs instead of error logs.
This change allows us to disable the LOG_I messages to reduce
overhead.
Removed LOG_VAR macro because it was used in only one place, and
a better solution is to simply use `__attribute__((unused))`.
Minor fixes, doesn't change anything. Not sure these are 'bugs' either,
but let's be polite with coverity scan...
One thing was not changed.
Coverity scan says:
*** CID 357991: Memory - illegal accesses (USE_AFTER_FREE)
/home/carabe/raphael/openairinterface5g/openair2/LAYER2/rlc_v2/rlc_entity_am.c: 507 in tx_list_remove_sn()
501 } else {
502 prev = cur;
503 cur = cur->next;
504 }
505 }
506
>>> CID 357991: Memory - illegal accesses (USE_AFTER_FREE)
>>> Using freed pointer "head.next".
507 return head.next;
508 }
509
510 void cleanup_sdu_list(rlc_entity_am_t *entity)
511 {
512 rlc_sdu_t head;
But as far as I understand, there is no problem. We don't access
head.next at all if it has been freed. Or is there some aliasing
going on there (pointer aliasing)? I doubt it. False positive?
Not sure if the problem is in the MAC layer or in the RLC v2 layer.
Maybe the buffer status reporting in RLC v2 is not good. Let's remove
two AssertFatal in the MAC for the time being.
Limitation: this fix only works if there is only one eNB,
because we force module_id = 0 in the function deliver_sdu where
(as the code is today) we have no way to know which module_id is
concerned. More generally, the rlc v2 does not work with more than
1 eNB.
The old method was wrong.
The new method is better, but not accurate, especially when the
TX buffer contains SDU of size > 2047 bytes.
Plus it's probably too slow.
To be refined at some point.
Melissa