OpenAFS Master Repository branch, openafs-stable-1_6_x, updated. openafs-stable-1_6_5-93-g4f14bf2

[Gerrit Code Review]

The following commit has been merged in the openafs-stable-1_6_x branch:
commit 4f14bf220e0fa75fda39dee2b4453b431555b388
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Aug 1 14:06:52 2013 -0500

    DAFS: Remove AFS_DEMAND_ATTACH_UTIL
    
    Currently we have two DAFS-related preprocessor defines in the
    codebase: AFS_DEMAND_ATTACH_FS and AFS_DEMAND_ATTACH_UTIL. DAFS_FS is
    the symbol for enabling DAFS code, and turns on demand attachment and
    all of the related complicated volume handling; it requires pthreads.
    DAFS_UTIL is supposed to be used for utilities interacting with DAFS,
    but do not have pthreads and so cannot build the relevant threads for
    e.g. the VLRU, so they don't support demand attachment and a lot of
    more advanced volume handling techniques.
    
    Having both of these exist is confusing. For example, currently in
    partition.c we only initialize dp->volLockFile for DAFS_FS, even
    though the structure exists if _either_ DAFS_FS or DAFS_UTIL is
    defined. This means when only DAFS_UTIL is defined, volLockFile will
    exist in the partition structure, but will be uninitialized!
    
    Amongst other possible issues, this means right now that DAFS_UTIL
    users (dasalvager is the only one right now) will try to use an
    uninitialized volLockFile whenever they try to use a volume that needs
    locking. Since the partition struct is usually initialized to all
    zeroes, this means we'll try to issue a lock request for FD 0,
    whatever FD 0 is. If FD 0 is not open, we'll fail with EBADF and bail
    out. But if FD 0 is open to some random file, the lock will probably
    succeed, and we'll proceed without actually locking the volume lock
    file. While the fssync volume checkout mechanism still works, the
    on-disk locking mechanism protects against race conditions the fssync
    volume checkout mechanism cannot protect against, and so handling
    volumes in this way is not safe.
    
    This is just one example; there are other issues with the partition
    headerLockFile and probably may other things; most instances of
    DAFS_FS really should be enabled for DAFS_UTIL as well.
    
    So, instead of trying to account for and fix all of these problems
    individually, get rid of AFS_DEMAND_ATTACH_UTIL, and just use
    AFS_DEMAND_ATTACH_FS. This means that all relevant code must be
    pthreaded, but since the only relevant code is for the dasalvager, we
    can just make dasalvager pthreaded. Salvaging does not make use of any
    threads or LWPs, so this should not have any side-effects.
    
    Thanks to Ralf Brunckhorst for reporting the issue where we encounter
    EBADF when FD 0 is not open, leading to the discovery of this.
    
    Reviewed-on: http://gerrit.openafs.org/10123
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
    (cherry picked from commit 7f15a1bbb34fa6f0d52800880f31be367d77a64f)
    
    Change-Id: I56904bc5989ffe346af9213584dee2ef5ce190ff
    Reviewed-on: http://gerrit.openafs.org/10167
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

 src/tsalvaged/Makefile.in |    4 ++--
 src/vol/partition.h       |   14 +++++++-------
 src/vol/salvager.c        |    4 ++--
 src/vol/vol-salvage.c     |   38 +++++++++++++++++++-------------------
 src/vol/volume.h          |    4 ++--
 src/vol/volume_inline.h   |   11 ++++-------
 6 files changed, 36 insertions(+), 39 deletions(-)

-- 
OpenAFS Master Repository