afs: Fix some afs_conn overcounts
authorAndrew Deason <adeason@sinenomine.net>
Sun, 14 Sep 2014 19:10:11 +0000 (14:10 -0500)
committerJeffrey Altman <jaltman@your-file-system.com>
Wed, 17 Dec 2014 15:55:04 +0000 (10:55 -0500)
commit54c0ee608f4afd2b178c9b60eabfc3564293d996
treef0e20c17be7a6b67bf1c4a8ba42780926c11722d
parent604f1eece60a8586642bb7006e2265913d2a4a25
afs: Fix some afs_conn overcounts

The usual pattern of using afs_Conn looks like this:

  do {
      tc = afs_Conn(...);
      if (tc) {
          code = /* ... */
      } else {
          code = -1;
      }
  } while (afs_Analyze(...));

The afs_Analyze call, amongst other things, puts back the reference to
the connection obtained from afs_Conn. If anything inside the do/while
block exits that block without calling afs_Analyze or afs_PutConn, we
will leak a reference to the conn.

A few places currently do this, by jumping out of the loop with
'goto's. Specifically, in afs_dcache.c and afs_bypasscache.c. These
locations currently leak references to our connection object (and to
the underlying Rx connection object), which can cause problems over
time. Specifically, this can cause a panic when the refcount overflows
and becomes negative, causing a panic message that looks like:

  afs_PutConn: refcount imbalance 0xd34db33f -32768

To avoid this, make sure we afs_PutConn in these cases where we 'goto'
out of the afs_Conn/afs_Analyze loop. Perhaps ideally we should cause
afs_Analyze itself to be called in these situations, but for now just
fix the problem with the least amount of impact possible.

FIXES 131885

Change-Id: I3a52f8ccef24f01d04c02db0a4b711405360e323
Reviewed-on: http://gerrit.openafs.org/11464
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Daria Brashear <shadow@your-file-system.com>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
src/afs/afs_bypasscache.c
src/afs/afs_dcache.c