Currently, in afs_GetDCache, if afs_AllocDCache fails, we retry for 5
minutes and then panic. Panicing in this situation is completely
unnecessary; afs_GetDCache can fail for a variety of other mundane
reasons (such as, if we can't fetch the requested data from the
relevant fileserver).
It may seem unusual for afs_AllocDCache to fail for over 5 minutes
(this is supposed to mean that we're out of dslots, and our attempts
to free up dslots have failed). However, afs_AllocDCache can also fail
if we are having issues in accessing the disk cache, and so we may not
be out of cache space or dslots at all; we just can't access the
cache. In this case, afs_AllocDCache can easily fail forever; waiting
longer or trying to free up cache space isn't going to help.
So, to avoid panicing in such situations, just make afs_GetDCache
return an error. We just need to make sure afs_xdcache is unlocked,
and then we can just jump to 'done', like plenty of other codepaths
do; no extra cleanup is required.
Also since we are removing a panic, add a log message when this
situation happens, so EIO errors don't suddenly pop up silently.
Reviewed-on: https://gerrit.openafs.org/13032
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit
0ff2364bd5e68c0a7587f8fbc552bf20b99d7039)
Change-Id: Ie29eed271b490edc943929710a87550e2d67b735
Reviewed-on: https://gerrit.openafs.org/13189
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Joe Gorse <jhgorse@gmail.com>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>