OpenAFS Master Repository branch, master, updated. openafs-devel-1_9_1-548-gab660e2

[Gerrit Code Review]

The following commit has been merged in the master branch:
commit ab660e2537999470a64304b0d5d817c491c44245
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Fri Aug 28 22:43:34 2020 -0400

    volser: Use GetLockedEntry in UV_ReleaseVolume
    
    Change UV_ReleaseVolume() to use the new GetLockedEntry() function. Add
    logic to GetLockedEntry() to support the special semantics of VL_SetLock
    for VLOP_RELEASE, to preserve the current behavior of UV_ReleaseVolume()
    with the VL_RERELEASE error code.
    
    The special semantics of the VL_RERELEASE error code with VLOP_RELEASE
    are a bit odd: this situation can currently only happen with our
    vlserver if the vlentry has the VLOP_RELEASE flag set but no lock
    timestamp. The only way that situation can occur with our current 'vos'
    is during a small window after a partially failed 'vos release'. Around
    where UV_ReleaseVolume() prints the message "The volume %lu could not be
    released to the following %d sites", we call VLDB_ReplaceEntry() with
    LOCKREL_TIMESTAMP, clearing just the lock timestamp but not the lock
    flags. We then jump to the 'rfail' label where we ubik_VL_ReleaseLock()
    with all LOCKREL_* flags are set, clearing the lock flags.
    
    So, the only time in this codepath where the lock timestamp is cleared
    but the VLOP_RELEASE flag is set is after the mentioned
    VLDB_ReplaceEntry() call but before the ubik_VL_ReleaseLock() call. If
    that last ubik_VL_ReleaseLock() fails, or if vos dies before reaching
    it, then the vlentry is left in a state that causes the VL_RERELEASE
    error code in the future. This behavior has existed since at least
    OpenAFS 1.0.
    
    Currently, the handling of this special VL_RERELEASE case is completely
    silent, so it's not clear that this is happening, if it does manage to
    happen. These special semantics are not really safe, since two vos
    processes could encounter a VL_RERELEASE volume at the same time, and go
    through the 'vos release' process in parallel thinking they have the
    vlentry locked, causing all kinds of problems.
    
    This behavior may be changed in the future, but for now just preserve
    the existing special handling of VL_RERELEASE. Add a warning message,
    though, to make this special situation not silent.
    
    No functional change (other than error messages) should be incurred by
    this commit.
    
    [adeason@sinenomine.net: Add VL_RERELEASE warning message and additional
    related comments.]
    
    Change-Id: I9da50677233f63235de730b5d234a9b575e196fd
    Reviewed-on: https://gerrit.openafs.org/14352
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>

 src/volser/vsprocs.c | 43 +++++++++++++++++++++++++++++++++----------
 1 file changed, 33 insertions(+), 10 deletions(-)

-- 
OpenAFS Master Repository