afs: Do not always ignore errors in afs_GetDSlot
authorAndrew Deason <adeason@sinenomine.net>
Wed, 21 Dec 2011 20:04:32 +0000 (15:04 -0500)
committerDerrick Brashear <shadow@dementix.org>
Tue, 27 Dec 2011 04:31:47 +0000 (20:31 -0800)
commit1a672914ab050811c99b6307c657630ab9b5c8ee
treeb7d2ea54040336f53221f5f387584ff41987c7b3
parent12177ba6fffaf8a693dd8c8e9445d5e7725ae743
afs: Do not always ignore errors in afs_GetDSlot

Currently afs_UFSGetDSlot will silently swallow any error in reading
the specified dslot from disk, and will return a "blank" dcache to the
caller. However, many callers of afs_GetDSlot will be asking for a
dcache that we know exists, and more importantly, we know is on the
global hash table. If a disk error is encountered and we're given a
"blank" dcache, we will erroneously believe the dcache entry is not on
the hash table, causing corruption of the hash table later on.

So instead, modify all callers of afs_GetDSlot to use either
afs_GetValidDSlot or afs_GetNewDSlot. Calling afs_GetValidDSlot
indicates that the given dentry index is known to be valid, and any
error encountered while reading the entry from disk should result in
an error (for disk I/O errors we have no control over, this results in
a NULL dentry returned; for internal consistency errors we panic).
Calling afs_GetNewDSlot indicates that the specified index may not
exist or may not be valid, and so returning a "blank" dentry in that
case is fine.

For memcache, the situation is the same, except any time we go to
"disk" it is an (internal) error, since there is no disk.

Change-Id: I53ea6e99649e4d6d5cbde58929dfcee1d45a3e7b
Reviewed-on: http://gerrit.openafs.org/6417
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
src/afs/afs_chunkops.h
src/afs/afs_dcache.c
src/afs/afs_disconnected.c
src/afs/afs_pioctl.c
src/afs/afs_prototypes.h
src/afs/afs_segments.c