trxcon/scheduler: be safe against a theoretical integer overflow

As was noted by Pau Espin Pedrol, there is a theoretical chance
that lchan->tdma.num_proc would overflow, so as a consequence,
subst_frame_loss() will be unable to compensate one
(potentionally lost) Downlink burst.

On practice, given the size of unsigned long and duration of a
single TDMA frame, it would only happen once in roughly ~6 years.

  FRAME_DURATION = 4615 * 10e-6
  ULONG_MAX = 2 ** 32 - 1

  FRAME_DURATION * ULONG_MAX -> ~198212740 seconds
                             -> ~55059 hours
                             -> ~2294 days
                             -> ~6 years.

Chances are that trxcon would crash much earlier, or even GSM
would be completely forgotten after such a long time run, but
let's work this around and simply start counting from 1
if that overflow eventually happens.

Change-Id: I3d40ef09b06039a85df52af06ab38de314e1a434

1 files changed, 10 insertions, 1 deletions

diff --git a/src/host/trxcon/sched_trx.c b/src/host/trxcon/sched_trx.c
index 1efae247..b53b0e83 100644
--- a/src/host/trxcon/sched_trx.c
+++ b/src/host/trxcon/sched_trx.c
@@ -721,7 +721,16 @@ int sched_trx_handle_rx_burst(struct trx_instance *trx, uint8_t tn,
 
 	/* Update TDMA frame statistics */
 	lchan->tdma.last_proc = fn;
-	lchan->tdma.num_proc++;
+
+	if (++lchan->tdma.num_proc == 0) {
+		/* Theoretically, we may have an integer overflow of num_proc counter.
+		 * As a consequence, subst_frame_loss() will be unable to compensate
+		 * one (potentionally lost) Downlink burst. On practice, it would
+		 * happen once in 4615 * 10e-6 * (2 ^ 32 - 1) seconds or ~6 years. */
+		LOGP(DSCHD, LOGL_NOTICE, "Too many TDMA frames have been processed. "
+					 "Are you running trxcon for more than 6 years?!?\n");
+		lchan->tdma.num_proc = 1;
+	}
 
 	return 0;
 }