STABLE12-afs-analyze-avoid-potential-loop-20030423

avoid potentially looping forever in e.g. afs_FetchStatus because
we exit afs_Analyze too early to increment busyCount, and despite having
areq->busyCount non-zero we have servers still not_busy which are already down
that we'll never talk to again. that combined with no conn means we never
touch most of afs_Analyze, exiting early with shouldRetry set.

incrementing busyCount whenever we exit with shouldRetry set should
ensure we can never end up looping forever.

(cherry picked from commit 42a1981fff5c9b3f4855e4f9200fb6a9de53642b)

diff --git a/src/afs/afs_analyze.c b/src/afs/afs_analyze.c
index 06f7d4c790ced4c6e4a1e5bd5abdaf95d95e7e4d..ede5606a3feb30d981e44e5b5a4946804ce531a5 100644 (file)
--- a/src/afs/afs_analyze.c
+++ b/src/afs/afs_analyze.c
@@ -384,6 +384,9 @@ int afs_Analyze(aconn, acode, afid, areq, op, locktype, cellp)
       } else {
        VSleep(afs_BusyWaitPeriod);         /* poll periodically */
       }
+      if (shouldRetry != 0)
+       areq->busyCount++;
+
       return shouldRetry; /* should retry */
     }