commit 3de6d0602f4c0c70b87d303161e154746a74b50d
author Neels Hofmeyr <nhofmeyr@sysmocom.de> Thu Apr 27 01:33:39 2017 +0200
committer Neels Hofmeyr <nhofmeyr@sysmocom.de> Mon May 15 10:40:34 2017 +0000
tree b3a73b8c61a366999b7faafe487db9e23cc2ee1e
parent 333d7e634551a7341e9a953d38d5ebbafc091787

fix PACCH paging: don't return early in case of NULL TBF

Commit b78a4a6dfef217c538d45949a6ae725e22a36b05 tried to fix a NULL dereference
error, but apparently was overly eager to return, because it looked like all
code paths would dereference the tbf.

In fact the code path further above, for msg != NULL, has "always" dereferenced
the tbf, but the lower code path, the one effecting the paging, has only
started to dereference tbf since shortly before the overly eager fix: in
da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7, to "update the dl ctrl msg counter
for ms". It seems that this tbf dereference in the paging path is bogus and the
cause for the segfault that made me write the early exit fix.

Fix that fix:

Do not exit early if tbf == NULL, stay in there to be able to reach the paging
path below.

In case of a message to be sent, assume that tbf is present, and verify: print
an error message and abort if there is a msg but no tbf, so that we will see
the error if I'm wrong there. If a tbf is missing, free the msg.

In case of no message, go on to send pending pagings, but do not attempt to
count ctrl messages for a tbf -- IIUC there will never be a tbf if we're
paging.

This should avoid segfaults while keeping PACCH paging intact.

Tweak a comment for and add a blank line above the paging section.

Related: OS#2176 CID#158969
Change-Id: Ib79f4a945e211a13ac7d1e511cc37b0940ac6202