openafs/ChangeLog

commit 8c307b42f0b0b80bcf69de09031991d2ab776ed9
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Thu Jun 17 17:03:16 2021 +0200

    Make OpenAFS 1.8.8
    
    Update version strings for the 1.8.8 release
    
    Change-Id: I8dc5b309ab17890410825caa329e536f14430d6b
    Reviewed-on: https://gerrit.openafs.org/14642
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 40a209edeeb984ab20b35cde666dac087bfc5eb0
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Thu Jun 17 16:59:56 2021 +0200

    Update NEWS for OpenAFS 1.8.8
    
    Finalize the release notes for the 1.8.8 release.
    
    Change-Id: I01b4527f708fbc8a733b3aa7754274c94683cb92
    Reviewed-on: https://gerrit.openafs.org/14641
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 270bb0998f149485e4ae251fce802d8e80794e7c
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Thu Jul 15 17:27:10 2021 +0200

    Make OpenAFS 1.8.8pre2
    
    Update version strings for the second 1.8.8 prerelease.
    
    Change-Id: Ie920e12fde0bc5043273d6dfceceaa1a4705ea3a
    Reviewed-on: https://gerrit.openafs.org/14699
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 67e7662714a39d00d77b7689c3457fdcc689f160
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Thu Jul 15 21:09:12 2021 +0200

    Update NEWS for 1.8.8pre2
    
    Release notes for the second 1.8.8 prerelease.
    
    Change-Id: I178d09bfa6c8d24b129cfdf92d4a4fb641518087
    Reviewed-on: https://gerrit.openafs.org/14700
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit d15cd1c8cfd431617ff29e9b83e79d82e1fa0d58
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jun 4 10:18:39 2021 -0600

    cf: Resolve implicit function definition for memset
    
    The autoconf function OPENAFS_HAVE_STRUCT_FIELD can produce a compiler
    warning for an implicit function definition for memset, however with
    macOS 11 (Big Sur) the default compiler flags have been changed
    (-Werror=implicit-function-declaration) so that this is now flagged as an
    error. As an error this can lead to an incorrect result returned by
    OPENAFS_HAVE_STRUCT_FIELD.
    
    Add an include for <string.h> to provide the necessary definition for
    memset.
    
    Note, both gcc and clang can produce the implicit function definition
    warning.
    
    Reviewed-on: https://gerrit.openafs.org/14631
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit fd5aa52ef8ce719502f970ab93ffde07d7ed4780)
    
    Change-Id: I6829f13ee2fb1698738e95b379928cfea383e348
    Reviewed-on: https://gerrit.openafs.org/14668
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 6fbbc7b579dc21b9229c24b1d0d577f7a7bd14fa
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jun 17 17:15:13 2021 -0500

    afs: Free pioctlToken in extractPioctlToken
    
    Ever since it was introduced in commit 5ec5ad5 (New GetToken pioctl),
    extractPioctlToken has incorrectly freed pioctlToken by passing
    '&pioctlToken' to xdr_free (instead of 'pioctlToken').
    
    This causes xdr_ktc_tokenUnion to interpret &pioctlToken (which is a
    struct ktc_tokenUnion **) as a struct ktc_tokenUnion *. This doesn't
    cause any corruption or panics, since ktc_tokenUnion doesn't contain
    any freeable fields unless its at_type is 2 (AFSTOKEN_UNION_KAD). So
    as long as the bogus 'at_type' from the misinterpreted pointer is not 2,
    the xdr_free call will just not free anything (and return an error,
    which we ignore).
    
    If the bogus at_type is 2, this would probably cause some memory
    corruption or other nastiness. For this to happen on 32-bit systems,
    the value of the 'pioctlToken' pointer itself would need to be 0x2.
    On 64-bit systems, the top or bottom 32-bits of the pointer would need
    to be 0x2 (depending on endianness). Those situations seem impossible
    or very unlikely on most systems, and have never been seen in the
    wild.
    
    FIXES 135238
    
    Reviewed-on: https://gerrit.openafs.org/14651
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 966d5eb58f1f4fb333f263f018429c3a782be344)
    
    Change-Id: Ied9b6c42106fa2c4353cccd08e1a6b50190a8504
    Reviewed-on: https://gerrit.openafs.org/14667
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5abea9b8b1164f203fe18b5abe7d64ac8cb514eb
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Tue Jun 22 20:02:18 2021 -0400

    bos: Let xdr allocate rpc output strings
    
    The bos client provides fixed sized buffers on the stack for RPC output
    strings instead of letting xdr allocate output strings.  Unfortunately,
    the fixed sized buffers do not account for the terminating nul char when
    the output string is the maximum size defined for the bozo RPCs.
    
    To avoid potential buffer overflows, and to allow for larger xdr string
    sizes in the future, convert these to xdr allocated strings. Be sure to
    always free the xdr allocated strings.
    
    The following bozo RPCs have xdr output strings, and are addressed in
    this commit:
    
    BOZO_EnumerateInstance
    BOZO_GetCellHost
    BOZO_GetCellName
    BOZO_GetInstanceInfo
    BOZO_GetInstanceParm
    BOZO_GetInstanceStrings
    BOZO_GetStatus
    BOZO_ListSUsers
    
    Thanks to Cheyenne Wills for pointing out this issue.
    
    Reviewed-on: https://gerrit.openafs.org/14650
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 9ae5b599c7289a6f3ea2b03f2646402da182bb5d)
    
    Change-Id: If8b23bbee3db83d65b7c7532fd47f3b5a16c424c
    Reviewed-on: https://gerrit.openafs.org/14666
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 6484bc7d5aa2dd15ed0fc6dbf7a3ddcf071f7dad
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Tue Oct 6 00:02:53 2020 -0400

    bos: do not assume fs just if dafs bnode is stopped
    
    If dafs is configured but stopped, 'bos salvage <fs> <vicep>
    -forceDAFS' will fail with:
    
      bos: failed to get instance info for 'fs' (no such entity)
      bos: shutting down 'fs'.
      bos: can't stop 'fs' (no such entity)
    
    This is due to incomplete logic in IsDAFS, introduced with commit
    e46f10a0a0a930f318833a8a86b10c19744160c1 'bos: Do not assume DAFS just
    if DAFS bnode exists'
    
    Add logic to IsDAFS to work correctly when dafs is configured but
    stopped.
    
    Reviewed-on: https://gerrit.openafs.org/14382
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 48df3ac30210056ec046b48c28aee425b0690f92)
    
    Change-Id: Ib55b9e322f529d120f424813c21af133ca2e6acc
    Reviewed-on: https://gerrit.openafs.org/14665
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 0b55780042d8f856c33ad7a97c65825e3ddee5b7
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Thu Jul 1 20:14:12 2021 -0400

    libadmin: Be sure to free the server list in ListCellsRPC
    
    Commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc added a check to avoid
    overrunning a buffer when the cell name returned by RXAFSCB_GetCellServDB
    is too large for the libadmin buffer, but in that case missed freeing
    the server list returned in the same rpc.
    
    Move the xdr_free() of the server list under the cleanup label so the
    server list returned by the RPC will always be freed.
    
    Thanks to Mark Vitale for finding this bug.
    
    Reviewed-on: https://gerrit.openafs.org/14690
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a5c146116faccc9891ae6d50506cd43d52dadb70)
    
    Change-Id: Ic310d8d940588db2c966130a1e7b0a9543dd5e23
    Reviewed-on: https://gerrit.openafs.org/14698
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 00423e6920fba66ce4ce7ab746210825830aae5b
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri May 21 12:38:01 2021 -0400

    libadmin: Let xdr allocate rpc output strings
    
    In most functions, the libadmin library provides fixed sized buffers for
    RPC output strings instead of letting xdr allocate the output string.
    Unfortunately the fixed sized buffers do not account for the terminating
    nul char when the output string is the maximum length possible for the
    xdr output strings.
    
    To avoid potential buffer overflows, and to allow for larger xdr string
    sizes in the future, convert these to xdr allocated strings and use safe
    string functions to copy the results to the application buffers. Fail
    with an error if the application buffer is too small, instead of
    overflowing the buffer or truncating results.
    
    Thanks to Cheyenne Wills for pointing out this issue.
    
    Reviewed-on: https://gerrit.openafs.org/14626
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 0d6b9defb36cb94f3d34b058f00055e9e99d85fc)
    
    Change-Id: Ia477d68ec62558470ae27544c86c340a7d2b7235
    Reviewed-on: https://gerrit.openafs.org/14664
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5b557f37ade19c0eb7073ee39808a16cf9508fd5
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Aug 21 11:48:53 2019 -0500

    afs: Update style in afs_tokens.c
    
    Fix a few style nits and other minor edits in afs_tokens.c. Mark a few
    functions 'static' that are not referenced outside of that file.
    
    Reviewed-on: https://gerrit.openafs.org/13806
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 1d2a1002bd1bc8d82c05399c06836ede83f9eeea)
    
    Change-Id: I85b263674477e63cdc72d4dd9b4f714611b71d7e
    Reviewed-on: https://gerrit.openafs.org/14663
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c978f92cbf9306c0b12eec68cd64ebac045c65e6
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Tue Jun 30 22:53:33 2020 +0200

    Make OpenAFS 1.8.8pre1
    
    Update version strings for the first 1.8.8 prerelease.
    
    Change-Id: Ia7468e6ae5ec93a81e13dda55842ec57135c2a03
    Reviewed-on: https://gerrit.openafs.org/14264
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit e9cc2c3c71eba2f5a1b1be1f5d4198385b681d5c
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Fri Feb 19 21:51:15 2021 +0100

    Update NEWS for 1.8.8pre1
    
    Release notes for the first 1.8.8 prerelease.
    
    Change-Id: I04762b28b3cc5528f31c2b5d8f1d7f906e46f62f
    Reviewed-on: https://gerrit.openafs.org/14540
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit f0283af65e81a4bc9aa4fa44eb8a4a45c6a0448e
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu May 27 11:02:01 2021 -0600

    afscp: Link against opr/roken/hcrypto
    
    Link afscp against libopr, libroken, and libafshcrypto, so afscp can
    be built again.
    
    Reviewed-on: https://gerrit.openafs.org/13656
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 4eeed830fa31b7b8b5487ba619acbc8d30642aaa)
    
    Change-Id: I73264df34743dcb6a8f6232267892ee602a76053
    Reviewed-on: https://gerrit.openafs.org/14627
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit d7900532e3e7897f8030a6ed31abff4ec0d32ebf
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Fri Jan 29 01:30:47 2016 -0500

    afs: free the Buffers array correctly during shutdown
    
    DInit() allocates 'Buffers' with afs_max_buffers = 4*nbuffers
    worth of buffer structs to allow for run-time expansion.
    
    But shutdown_bufferpackage() free 'Buffers' as if it only had
    nbuffers worth of buffer structs.
    
    Correct the size of Buffers passed to afs_osi_Free().
    
    Discovered during Solaris shutdown testing with kmem_flags=x0f.
    This bug is not Solaris-specific, but it may be symptomless on other
    platforms.
    
    Introduced by commit e7c966354c428a5a5929a3db6a829ee71c8ba2fc 'Flexible
    client buffer growth'; this only affected cold shutdowns (afsd
    -shutdown).
    
    After commit 2336164d1bf63980419d3a870f908f1f384fdfc0 'afs: Actually
    free resources during warm shutdown', this bug also affects warm
    shutdowns (the default when /afs is unmounted).
    
    Reviewed-on: https://gerrit.openafs.org/12183
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit d1c944ec167b8845d703a6b6a8d9492751056b98)
    
    Change-Id: I612b33a3788d2c9a0c39c5cb22a3473f8e1c01e1
    Reviewed-on: https://gerrit.openafs.org/14616
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5cfee79d9a12e67720906cc5a985f7c12064db41
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 21 17:02:34 2019 -0500

    afs: Actually free resources during warm shutdown
    
    Currently, the shutdown_*() code paths for several subsystems only
    free the memory for that subsystem for "cold" shutdowns, and not for
    "warm" shutdowns. This means the memory gets leaked during a "warm"
    shutdown, since we never free these resources anywhere else.
    Specifically, this happens in shutdown_bufferpackage, shutdown_AFS,
    and shutdown_osinet.
    
    To avoid these leaks for warm shutdowns, just move the
    afs_cold_shutdown check around a little, so we free the relevant items
    in either codepath.
    
    Reviewed-on: https://gerrit.openafs.org/13716
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 2336164d1bf63980419d3a870f908f1f384fdfc0)
    
    Change-Id: I1d2360ea777b7a7488e599b6e707c98295d8fbdd
    Reviewed-on: https://gerrit.openafs.org/14615
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 4d03c0cac0abe575ccf1a74078c3338245690462
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Jul 30 16:42:19 2020 -0400

    vol: ensure ih package defaults are set for salvage
    
    Like most OpenAFS components that work with ihandles, salvager relies on
    implicit invocation of ih_PkgDefaults via the one-shot in the first call
    to IH_INIT.
    
    Unfortunately, there is at least one reachable code path in salvager
    that asserts (panics) because vol_io_params has not yet been
    initialized.  This is when salvaging a volume group that does not have a
    link table; the salvager then panics while attempting to create a new
    link table:
    
    SalvageFileSys -> SalvageFileSys1 -> DoSalvageVolumeGroup ->
    CreateLinkTable -> IH_CREATE -> namei_icreate -> icreate ->
    namei_SetLinkCount -> FDH_SYNC -> ih_fdsync -> osi_Assert(0)
    
    This path was discovered while testing the non-dafs salvager, but it has
    also been observed in the field with the DAFS salvageserver.  It is
    possible that there are additional undiscovered paths where
    vol_io_params are required but uninitialized.
    
    Add an implicit ih_PkgDefaults call to icreate to avoid triggering the
    assert via the code path above.
    
    Reviewed-on: https://gerrit.openafs.org/14378
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 9d65bcf8833a826a74fc433777599380cd5b03b9)
    
    Change-Id: I8c7fb5acbaf2d84b290ce95e11a7baf0421b920d
    Reviewed-on: https://gerrit.openafs.org/14614
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 90e54b2a2010b4620b007ea5c8d3a5a7cbc30069
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Fri Oct 9 16:28:15 2020 -0400

    vol: move ih_PkgDefaultsSet check inside ih_PkgDefaults
    
    Instead of repeating the oneshot check in each caller of ih_PkgDefaults,
    move the oneshot check into ih_PkgDefaults itself.
    
    While here, ensure that ih_PkgDefaults does its work under IH_LOCK.
    
    Finally, make ih_PkgDefaultsSet a local static variable (no longer
    exported).
    
    Reviewed-on: https://gerrit.openafs.org/14383
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 896524963ca1f1d8144a668dafefc8ce88ad440b)
    
    Change-Id: I179640df6e0a5fd6b9a97b57cfde6377213e1d14
    Reviewed-on: https://gerrit.openafs.org/14613
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 1b794441fe2c7d3c22ca92135035b5ebe826431f
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Oct 1 17:13:51 2020 -0400

    afsd: remove unused variable afs_shutdown
    
    Since the original IBM code import, the variable afs_shutdown has been
    set but never read.
    
    Remove it from the code base.
    
    No functional change is incurred by this commit.
    
    Reviewed-on: https://gerrit.openafs.org/14380
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 0761bb7c58260985fbbfcf477d597da3c5d64fc5)
    
    Change-Id: I35d657fb93b9e6f611d91d5a374899249cec5b88
    Reviewed-on: https://gerrit.openafs.org/14612
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 553270ec9e02fc36bdb59924344fa4f470ee20cc
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Jan 28 23:38:59 2016 -0500

    afs: remove duplicate declaration for afs_shutdown()
    
    Somehow there were two.  Now there is but one.
    
    Reviewed-on: https://gerrit.openafs.org/12181
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 3e2fe677a2d3b9f76644175f3a59d392872b87f3)
    
    Change-Id: I19a2f0ebe2c79fd32800cc388e488fa11fd8f0ce
    Reviewed-on: https://gerrit.openafs.org/14611
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7ebe9b70b994ba04d016a5bbf479f30934b7c632
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Jan 28 10:01:13 2016 -0500

    afs: afsd -shutdown sets afs_cold_shutdown too soon
    
    'afsd -shutdown' always invokes syscall(AFSOP_SHUTDOWN)
    with parm2 set to 1 to indicate a "cold" shutdown.
    (There are no other callers to AFSOP_SHUTDOWN).
    
    AFSOP_SHUTDOWN sets global variable afs_cold_shutdown
    based on the value of parm2.  Then it checks to see if
    AFS is still mounted; if so, we return early with EACCES.
    However, global afs_cold_shutdown remains set.
    
    Therefore, the next successful 'umount' after a "failed"
    'afsd -shutdown' will always trigger a "cold" shutdown.
    This is contrary to the intent of the current implementation,
    which is to perform a "warm" shutdown upon 'umount' for
    most platforms.  (Exceptions:  AIX, OBSD, NBSD always
    specify a cold shutdown upon 'umount').
    
    This bug would never be noticed on the "cold" exception
    platforms, but on the "warm" platforms the inconsistency
    of seeing an unexpected "COLD" shutdown may be confusing
    and surprising.
    
    Make shutdown operation more self-consistent by modifying
    AFSOP_SHUTDOWN to defer setting of afs_cold_shutdown until
    after the mount test.
    
    Reviewed-on: https://gerrit.openafs.org/12180
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit c72ec68bcea646aa3e0395ad103afb2ee9ba9cde)
    
    Change-Id: I7b40728bcb56c9bb0d86912f140fed315e93bf64
    Reviewed-on: https://gerrit.openafs.org/14610
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit de668dbafb55682a209f71cb1d09b5084d0c2af1
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Fri Apr 9 15:14:52 2021 +0000

    macos: delegate sock_* calls to bkg daemons
    
    As part of Apple's ongoing effort to modernize macOS, improve security
    and reliability, the deprecation of kernel extensions was officially
    announced at WWDC19. According to this announcement, Kernel programming
    interfaces will be deprecated as alternatives become available, and
    future OS releases will no longer load kernel extensions that use
    deprecated KPIs by default.
    
    Unfortunately, the following KPIs, extensively used by rx, are included
    in the list of deprecated KPIs as of macOS 10.15:
    
    - sock_receivembuf
    - sock_close
    - sock_send
    - sock_socket
    - sock_setsockopt
    - sock_bind
    
    To workaround this problem, delegate calls to the functions mentioned
    above to bkg daemons forked by afsd. Notice that the ifadd_* and ifnet_*
    functions are also deprecated. Fortunately, these calls can be avoided
    enabling AFS_USERSPACE_IP_ADDR.
    
    Thanks to Andrew Deason for his assistance (ideas, suggestions,
    documentation, etc).
    
    Reviewed-on: https://gerrit.openafs.org/14431
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 70e5c4f6a45854ae3a4241568769279747a8b76f)
    
    Conflicts:
    	src/config/afs_args.h
    
    Change-Id: I4370c0aa3978f208c763ed43c3cc5567ee74e730
    Reviewed-on: https://gerrit.openafs.org/14600
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7f7ff82c0ab57ee23f19c3ea783ab8ebf23ca045
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Aug 14 15:53:20 2018 -0500

    afs: Add AFS_USPC_SHUTDOWN bkg request
    
    When AFS_NEW_BKG was added, the kernel module indicated to the
    relevant afsd process that it's time to shutdown by returning -2. This
    works on DARWIN, but it's difficult to make this work on all
    platforms, because of the different way that platforms handle error
    codes from our pioctls and other AFS syscalls.
    
    Specifically, on LINUX, negative error codes are assumed to be
    negative errno codes, and so returning -2 from the syscall handler
    means we return -1 to userspace, with errno set to 2 (ENOENT).
    
    Getting this to work consistently across platforms is probably more
    trouble than its worth, so instead of relying on specific return codes
    from the syscall, just add a new background daemon operation called
    AFS_USPC_SHUTDOWN, which just tells the background daemon to exit.
    
    Reviewed-on: https://gerrit.openafs.org/13281
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 397199a1992d74d8b7e693a2d76df836f7a70080)
    
    Change-Id: Ib809a27476f49baef70dcbcc749eed95a4de8d2f
    Reviewed-on: https://gerrit.openafs.org/14605
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a80e04a9eb6fb6b3d4cffce0a682931f63efc933
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Thu Jan 28 15:49:25 2021 -0800

    macos: packaging support for MacOS X 11.0
    
    This commit introduces the new set of changes / files required to
    successfully create the dmg installer on OS X 11.0 "Big Sur".
    
    Reviewed-on: https://gerrit.openafs.org/14430
    Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 40c6f3aa5576d7e1ac23caff1ae4ffd69e74dc44)
    
    Change-Id: I55bab1631c41fdb636fa84359f2d76d4bfc2b6a1
    Reviewed-on: https://gerrit.openafs.org/14598
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 3ea37d57106901e8d4e82537dcee3609f1ef2c1e
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Thu Jan 28 14:45:10 2021 -0800

    macos: add support for MacOS 11.0
    
    This commit introduces the new set of changes / files required to
    successfully build the OpenAFS source code on OS X 11.0 "Big Sur".
    
    While here, refactor the code that checks if the "-Xlinker -kext"
    system-specific linker option is needed.
    
    Reviewed-on: https://gerrit.openafs.org/14429
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit acc955bc17e1a1e10f634e7017c1323954f07b31)
    
    Change-Id: Ie5b791c7444612c617eeb3b16e1165510fe9f251
    Reviewed-on: https://gerrit.openafs.org/14597
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c7a8bf889ddacf1935282da14e06abf0e63999f7
Author: Andrew Deason <adeason@dson.org>
Date:   Fri Dec 20 22:09:35 2019 -0600

    rx: Indent ifdef maze in rx_kcommon.c
    
    Reviewed-on: https://gerrit.openafs.org/13997
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 08c769967ca12f1ac99c736789f1925763d8a115)
    
    Change-Id: I75d5ec5c9f75f79817adec3f259e546e79fc3629
    Reviewed-on: https://gerrit.openafs.org/14599
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit efac54c67d527fb8a4fa118f53fc55ad75c7d2ff
Author: Andrew Deason <adeason@dson.org>
Date:   Fri Dec 20 21:51:18 2019 -0600

    afs: Indent ifdef maze in afs_server.c
    
    Reviewed-on: https://gerrit.openafs.org/13996
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 2a8db42664cc450c2db097fe19472fe7876203df)
    
    Change-Id: Iff5bb059ea7005c4f174401b9daa45f1ae6d092d
    Reviewed-on: https://gerrit.openafs.org/14604
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7550806b15b3347c70520b23d5f7f59665e8d4a0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Mar 18 08:28:22 2021 -0600

    bozo: Fix the test for bosserver '-cores none'
    
    The check for the '-cores none' parameter is incorrect resulting in the
    parameter to be taken as a directory path.
    
    Update the string comparison.
    
    Reviewed-on: https://gerrit.openafs.org/14559
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 000fe6b7e6e7bf140c7cca7becc8fb7e8006fec7)
    
    Change-Id: I45ac645bb7cdd6f3cd1dfd81d6ccdc9cda4547a8
    Reviewed-on: https://gerrit.openafs.org/14589
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 3c19cf40f4016931accc97c555bc5b623b838e96
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Dec 7 14:42:54 2020 -0500

    vol: always build vol-bless utility
    
    In order to avoid future bit-rot, always build vol-bless.  Also add it
    to the clean rule.  However, continue to leave it undistributed and
    uninstalled by default.
    
    Reviewed-on: https://gerrit.openafs.org/14464
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 1efa4e49f2dabe2f3a1ef235e21a96ae9d5ff6bf)
    
    Change-Id: I62b2f192e2bcb24221c94468e2e72aaa567568d4
    Reviewed-on: https://gerrit.openafs.org/14601
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 91a298cc1fb93ffa8766f291b5a1c7ab29ad6f84
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Dec 7 14:40:33 2020 -0500

    vol: add vol-bless to .gitignore
    
    No functional change is incurred by this commit.
    
    Reviewed-on: https://gerrit.openafs.org/14463
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 986ee6a0a70d70f366baeb43670eb367f0525b97)
    
    Change-Id: I1819537c8ac26101a81100871f85a6de78408cea
    Reviewed-on: https://gerrit.openafs.org/14602
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b6c9bf43988d5945e502be1c9455adc791539a72
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Dec 7 13:13:28 2020 -0500

    vol: make vol-bless buildable again
    
    The vol-bless utility is not built by default and so is subject to
    bit-rot.  Thus commit 170dbb3ce301329ff127bb23fb588db31439ae8d 'rx: Use
    opr queues' overlooked vol-bless.c when adding includes for users of
    struct rx_queue.
    
    Add the required #include <rx/rx_queue.h> so vol-bless builds again.
    
    Note to maintainers: this change is only required for 1.8.x and later;
    vol-bless builds fine in 1.6.x and earlier releases.
    
    Reviewed-on: https://gerrit.openafs.org/14462
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit e1f20287a4d0cd80c6bfe7309b907fe5a4ac1464)
    
    Change-Id: I1f9acb176758bd34b7f63d5ebde54e9af191ad77
    Reviewed-on: https://gerrit.openafs.org/14603
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 67385e65cbdb41a8b2895a7fe1d637c7b899ef5c
Author: Tim Creech <tcreech@tcreech.com>
Date:   Thu Oct 29 21:29:10 2020 -0400

    FBSD: Add support for FreeBSD 12.2
    
    Reviewed-on: https://gerrit.openafs.org/14474
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 96ebee44c322934b9eda1bab5907ee87b03d571f)
    
    Change-Id: I95dedbee8b67a2bb05a8bb3614045fa3a49f9a11
    Reviewed-on: https://gerrit.openafs.org/14590
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c58313fc4f1c04e1d3f94f53b966516b2560e4c2
Author: Tim Creech <tcreech@umd.edu>
Date:   Mon Dec 9 21:13:58 2019 -0500

    FBSD: Add support for FreeBSD 12.1
    
    Reviewed-on: https://gerrit.openafs.org/13982
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 71ce9fff8e682a77e17490a54e091656cbf96925)
    
    Change-Id: I4214101d314cac6d677a08f760ccf990a4441306
    Reviewed-on: https://gerrit.openafs.org/14537
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 4b14b60afbf28f5fcf325ee378a26657f7780254
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Tue Aug 18 13:56:26 2020 +0000

    bos: suppress unnecessary warn if -noauth
    
    Commit d008089a7 (Add interface to select client security objects)
    consolidated the code that selects the client security objects into a
    set of new interfaces. Before this commit, the "bos: running
    unauthenticated" message, which warns the user when an unauthenticated
    connection is established, used to be suppressed if the -noauth flag was
    specified.
    
    Similarly to commit b3c16324e (ubik: Make ugen_ClientInit honor
    noAuthFlag), recover the original behavior avoiding warn messages about
    unauthenticated connections if the -noauth flag is provided.
    
    Reviewed-on: https://gerrit.openafs.org/14306
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit d5f0e16ac44475be55a7cc3e2895fc4a3a923ece)
    
    Change-Id: Id78494c2a189f2e99e25111200cabde32a4add2b
    Reviewed-on: https://gerrit.openafs.org/14546
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c747b15dd2877e6d17e3e6b940ae78c1e1ccd3ea
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Mar 5 16:31:03 2021 -0700

    Linux 5.12: Add user_namespace param to inode ops
    
    The Linux commits:
    "fs: make helpers idmap mount aware" (549c72977) and
    "attr: handle idmapped mounts" (2f221d6f7) that were merged into
    Linux-5.12-rc1 cause a build failure when creating the kernel module.
    
    Several functions within the inode_operations structure had their
    signature updated to include a user_namespace parameter.  This allows
    a filesystem to support idmapped mounts.
    
    OpenAFS only implements some of the changed functions.
    
       LINUX/vnodeops function inode_operation
       =====================   ===============
       afs_notify_change       setattr
       afs_linux_getattr       getattr
       afs_linux_create        create
       afs_linux_symlink       symlink
       afs_linux_mkdir         mkdir
       afs_linux_rename        rename
       afs_linux_permission    permission
    
    Update the autoconf tests to determine if the Linux kernel requires
    the user_namespace structure for inode_operations functions. If so,
    define a generic "IOP_TAKES_USER_NAMESPACE" macro.
    
    Update the above vnodeops functions to accept a 'struct user_namespace'
    parameter.
    
    When using the 'setattr_prepare' function a user namespace must be
    now provided. In order to provide compatibility as a non-idmapped mount
    filesystem the initial user namespace can be used. With OpenAFS, the
    initial user namespace obtained at kernel module load time is stored in
    a global variable 'afs_ns'.
    
    Update the call to setattr_prepare to pass the user namespace pointed
    to by the 'afs_ns' global variable.
    
    Update calls to setattr to pass the user namespace pointed to by
    the 'afs_ns' global variable.
    
    Notes:
    
    The changes introduced with Linux 5.12 allow a filesystem to support
    idmapped mounts if desired. This commit does not implement support for
    idmapped mounts, but will continue to use the same initial user
    namespace as prior to Linux 5.12.
    
    With Linux 5.12 the following autoconf checks fail:
    
     HAVE_LINUX_INODE_OPERATIONS_RENAME_TAKES_FLAGS
     HAVE_LINUX_SETATTR_PREPARE
     IOP_CREATE_TAKES_BOOL
     IOP_GETATTR_TAKES_PATH_STRUCT
     IOP_MKDIR_TAKES_UMODE_T
    
    The new macro 'IOP_TAKES_USER_NAMESPACE' covers the cases where these
    macros where used.
    
    Reviewed-on: https://gerrit.openafs.org/14549
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 1bd68506be3243c5670aaf53798b2e4e715d4c8b)
    
    Change-Id: I8cd54042da4e0295f3cf8417c84138bb0458f881
    Reviewed-on: https://gerrit.openafs.org/14565
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5a5d358b02b88d6d2c7a27a75149e35b1de7db38
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Mon Mar 8 09:22:04 2021 -0700

    Linux: Create wrapper for setattr_prepare
    
    Move call to setattr_prepare/inode_change_ok into an osi_compat.h
    wrapper called 'afs_setattr_prepare'.  This moves some of the #if logic
    out of the mainline code.
    
    Reviewed-on: https://gerrit.openafs.org/14548
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 12ae2beeeb172cebdfa24d5ea149f73fd85541f8)
    
    Change-Id: I1c7806893daf2404a8b3ac1b5c88ca04e6409226
    Reviewed-on: https://gerrit.openafs.org/14564
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit cdec210405afb47ee338bfde9280710b64d7abc6
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Jul 23 13:50:31 2019 -0500

    LINUX: Introduce afs_d_path
    
    Move our preprocessor logic around d_path into an osi_compat.h
    wrapper, called afs_d_path. This just makes it a little easier to use
    d_path, and moves a tiny bit of #ifdef cruft away from real code.
    
    Reviewed-on: https://gerrit.openafs.org/13721
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 4c4fb6e36634e5663c8be25acd4a1ac872e4738c)
    
    Change-Id: I08763c71006e4ac6f2bf88d8ac71941fc44e6ab8
    Reviewed-on: https://gerrit.openafs.org/14563
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8cdd8ad84006b17bfe243b004f0c4191c7df3af5
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Apr 12 22:28:29 2020 -0500

    tests: Skip SIGBUS test on FreeBSD
    
    Currently, 'softsig-helper -buserror' causes a SIGBUS on most
    platforms, but can result in SIGSEGV on FreeBSD by default (at least
    on 11.3-RELEASE). Skip the test on FreeBSD, until we can provide a
    more reliable way to generate SIGBUS.
    
    Note that when the sysctl machdep.prot_fault_translation is set to 1,
    'softsig-helper -buserror' generates a SIGBUS instead of SIGSEGV,
    suggesting that generating a SIGBUS here is the old 'compat' behavior.
    When machdep.prot_fault_translation is 0 (the default), the code path
    in the FreeBSD kernel that dictates whether to send a SIGBUS or
    SIGSEGV in this situation depends on some autodetection heuristics,
    and so may produce different results depending on FreeBSD releases or
    even compiler settings (due to detection of ABI based on some ELF
    notes in the relevant binary).
    
    For some details on this sysctl, see
    <https://www.freebsd.org/news/status/report-2019-07-2019-09.html#Signals-delivered-on-unhandled-Page-Faults>
    or the FreeBSD source code. In 11.3-RELEASE, the decision to issue a
    SIGBUS or SIGSEGV can be found around sys/amd64/amd64/trap.c:355.
    
    Reviewed-on: https://gerrit.openafs.org/14145
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit df5480057c2994914e22bd14b169dbcd8857485a)
    
    Change-Id: Ifd2c17c52a7a9be7a8a09776cf15500fdc9ca62d
    Reviewed-on: https://gerrit.openafs.org/14536
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5c1aa944d73e20272fa886e46ba0d4e69c54e8db
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Sep 8 16:10:40 2019 -0500

    FBSD: Remove MA_* abstractions
    
    In FBSD/osi_vnops.c, we have a few abstractions (e.g. MA_VOP_UNLOCK)
    that used to expand to different things for older FreeBSD versions.
    Currently, they always expand to the same thing, so just remove the
    abstractions.
    
    While we are changing these calls, also change one instance of
    MA_VOP_LOCK to vn_lock (instead of VOP_LOCK), since we're not usually
    supposed to call VOP_LOCK directly, according to the VOP_LOCK(9)
    manpage. The MA_VOP_LOCK call was added in commit bd707fb7
    (freebsd-almost-working-client-20020216), seemingly by mistake.
    
    Reviewed-on: https://gerrit.openafs.org/13843
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 7260c7164b9a2199c7b5f83279fa18af16e7d387)
    
    Change-Id: I831e798546da97eeba923965c24dd79be14a9b89
    Reviewed-on: https://gerrit.openafs.org/14535
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b03f8b684077c9224fe059abf8c316739096e0cd
Author: Tim Creech <tcreech@umd.edu>
Date:   Fri Dec 13 22:24:57 2019 -0500

    FBSD: Build vnode_if.h before libafs objs
    
    Currently, if we are building with -j2 or higher, we can easily fail
    to build some libafs objects because vnode_if.h does not exist yet.
    vnode_if.h is generated by the FreeBSD build, but none of our objects
    depend on it, so during parallel builds it may not be available by the
    time we build, for example, src/external/heimdal/hcrypto/sha256.c.
    
    This results in build errors that can look like this:
    
        --- sha256-kernel.o ---
        cc -I. -I.. -I../nfs [...]/src/external/heimdal/hcrypto/sha256.c
        In file included from [...]/src/external/heimdal/hcrypto/sha256.c:34:
        In file included from [...]/src/crypto/hcrypto/kernel/config.h:30:
        In file included from [...]/src/afs/sysincludes.h:354:
        /usr/src/sys/sys/vnode.h:588:10: fatal error: 'vnode_if.h' file not found
        #include "vnode_if.h"
                 ^~~~~~~~~~~~
        1 error generated.
        *** [sha256-kernel.o] Error code 1
    
        make[4]: stopped in [...]/src/libafs/MODLOAD
        1 error
    
    To avoid this, make all of our libafs objects depends on vnode_if.h.
    
    [adeason@dson.org: Expanded commit message.]
    
    Reviewed-on: https://gerrit.openafs.org/13983
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 0ee53d2fe9341e60f420662749d5ae8c6d4b5f24)
    
    Change-Id: I85696c23aeeabf8ebc38c8a9ea320fdcf8141ad9
    Reviewed-on: https://gerrit.openafs.org/14534
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8825b5346f67f2193e770d524d4524b2ff16d84a
Author: Tim Creech <tcreech@tcreech.com>
Date:   Sun Mar 5 18:15:58 2017 -0500

    FBSD: Remove LOCKPARENT/ISLASTCN lookup logic
    
    Currently, our afs_vop_lookup on FBSD tries to only lock 'dvp' for
    ISDOTDOT requests when LOCKPARENT and ISLASTCN are set. There are a
    couple of problems with this:
    
    - The conditional locking logic involving LOCKPARENT/ISLASTCN is only
      relevant in very old FreeBSD releases (per-fs checking of these
      flags for parent locking went away around the FreeBSD 6 era).
    
    - Our current logic here is wrong anyway, since we try to lock 'dvp'
      twice when those flags are set. This was mostly introduced by commit
      2f6be821 (FBSD: band-aid vnode locking in lookup), which added a
      lock/unlock pair for 'dvp' around the lock for 'vp', even though
      'dvp' was unlocked several lines earlier.
    
    This means that if we hit the relevant code path, we will deadlock,
    since we try to lock 'dvp' twice. To avoid this, just remove the
    relevant logic for LOCKPARENT/ISLASTCN, since it is only relevant for
    old FreeBSD releases that are not supported by us or FreeBSD.
    
    Add and rearrange some comments around here to try to more explicitly
    explain the relevant locking rules.
    
    [adeason@dson.org: Commit message rewrite, adding comments, removing
    old FreeBSD code.]
    
    Reviewed-on: https://gerrit.openafs.org/12578
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 17a845c8d44f453b09b21afd59182e616234e872)
    
    Change-Id: I105dfe397bb723b0939bb626103d857007e1a7bf
    Reviewed-on: https://gerrit.openafs.org/14533
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 27268300531101748069741f9deaae5e160616a8
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Apr 12 22:40:14 2020 -0500

    FBSD: Remove unused 'wantparent' logic
    
    In afs_vop_lookup, the 'wantparent' variable doesn't actually change
    any logic in the function. In the if() clause that it's used, the
    value of 'wantparent' is only ever used if cnp->cn_nameiop is RENAME
    and ISLASTCN is set. But if both of those are true, then the second
    half of the if() conditional will always be true, so the value of
    'wantparent' doesn't matter.
    
    So to remove this confusing unused logic, remove the 'wantparent'
    local var, and all its associated logic.
    
    Issue spotted by kaduk@mit.edu.
    
    Change-Id: Ia63b88d67d21cc2b81a0c25aa31ea60ab202b0a7
    Reviewed-on: https://gerrit.openafs.org/14143
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7df5c003ed6eb17a693d67ffdfc0556f0c569cc1)
    Reviewed-on: https://gerrit.openafs.org/14532
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fa25fb8f53f8a31556b6aa189becef5850cc068a
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Aug 18 19:59:50 2019 -0500

    FBSD: Add support for FreeBSD 11.3
    
    Reviewed-on: https://gerrit.openafs.org/13792
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7116de596a8f1d0be3da6eebe92d486f57aefd02)
    
    Change-Id: I9bbf3a72041dda4220b63963b6fc9bd8bd2342e8
    Reviewed-on: https://gerrit.openafs.org/14531
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ed6170582ce6fc9fc501349aa98ccc726c04501b
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Dec 1 15:39:04 2019 -0600

    FBSD: Declare vnops/vfsops static
    
    Declare our vnode and vfs operations as static functions, since they
    are not referenced outside of osi_vfsops.c/osi_vnodeops.c. Shuffle
    around the definitions in osi_vnodeops.c so that we don't need forward
    declarations for the functions.
    
    Reviewed-on: https://gerrit.openafs.org/13973
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 37c5db3ce767868803135c916b282ff2e541d052)
    
    Change-Id: I8817e0e2a02bc4211dc84c0d9f8b418de756120e
    Reviewed-on: https://gerrit.openafs.org/14530
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 60f3f689c4a0bd152e1c5a2fe660a3c59933491e
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Aug 25 23:21:23 2019 -0500

    FBSD: Remove pre-8 code
    
    Commit 123f0fb1 (config: remove support for old FreeBSD releases)
    removed our support for FreeBSD releases before FreeBSD 8. However,
    various areas of code still reference the symbols from those old
    versions (e.g. AFS_FBSD53_ENV). Remove our ifdef logic for these old
    symbols, according to the following rules:
    
    - In FBSD-specific dirs, assume AFS_FBSD80_ENV is always true (as well
      as the symbols for earlier versions)
    
    - In non-FBSD dirs, convert AFS_FBSD80_ENV to AFS_FBSD_ENV (and do the
      same for all earlier versions)
    
    This allows us to remove code that was specific to older FreeBSD
    versions, and simplify some ifdef conditionals.
    
    Also remove the definitions for AFS_FBSD80_ENV and earlier versions in
    our existing param.h files.
    
    With this commit, the functions afs_start, afs_vop_lock,
    afs_vop_unlock, and afs_vop_islocked are now always unreferenced, so
    remove them.
    
    Reviewed-on: https://gerrit.openafs.org/13812
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 847b63af92dd527de31675a0c3c82c9a57e6c4b3)
    
    Change-Id: Icaaf660a95084a358d1ddf6fbc63944eff90492f
    Reviewed-on: https://gerrit.openafs.org/14529
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit dcda95f388426e6bf6ace5f86905f0cf695e8413
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jun 23 17:48:53 2019 -0500

    libafs: Create debug KMODDIR for FBSD debug inst
    
    Commit 99418024 (libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst)
    made it so we create the kmod installation dir before copying our
    module into it. However, if we build a 'debug' variant of our module,
    the FreeBSD build process also installs debug symbols in a different
    directory, ${DESTDIR}${KERN_DEBUGDIR}${KMODDIR}, which may not exist.
    So do the same thing for that dir too, if --enable-debug-kernel is
    turned on, so the build still works.
    
    To do this, introduce the LIBAFS_REQ_DIRS var, to make it easier to
    keep track of which dirs we may need to create.
    
    Reviewed-on: https://gerrit.openafs.org/13690
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 3bc03e7a5f8ef521e71a30cb8e66e07e2d1b4605)
    
    Change-Id: Idee5614e92b99bd1140a3cef971537fb68eec151
    Reviewed-on: https://gerrit.openafs.org/14528
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 44d7a30657d8b507e5d382c68b8411b8437c2af2
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 14 17:31:30 2019 -0500

    FBSD: Use ucontext for FreeBSD 10+ on amd64
    
    Currently, running any LWP program on recent FreeBSD on amd64 causes
    (or can cause) a SIGBUS very quickly. This is possibly because our
    stack management code in LWP only ensures our stacks are 4 or 8-byte
    aligned in most cases (except DARWIN, which gets 16-byte-aligned
    stacks), according to the value of STACK_ALIGN. The amd64 ABI mandates
    that stacks be 16-byte-aligned, and some function calls assume that
    this is followed, causing a SIGBUS when it is not. FreeBSD on amd64
    currently uses process.amd64.s for its savecontext() implementation,
    which does not do any checking or fixup of the stack alignment.
    
    This behavior has been observed on amd64 with FreeBSD 11 specifically,
    but it probably happens on any FreeBSD release when using clang.
    FreeBSD switched to clang as the default compiler with FreeBSD 10, so
    this probably occurs with FreeBSD 10 and newer.
    
    We could perhaps try to fix this by changing our stack management
    code, but we can also avoid most of this nonsense by just using
    ucontext instead of our custom assembly code. So, do that, by setting
    USE_UCONTEXT for FreeBSD 10+. Also enable the same 'stackvar'-based
    workaround in savecontext() as Linux uses, since otherwise 'topstack'
    appears to always be NULL, and triggers our stack overflow checks.
    
    Note that while LWP use is deprecated, as of this commit many small
    utilities (like 'fs') are still linked to LWP, and so are unusable
    without a fix like this.
    
    Reviewed-on: https://gerrit.openafs.org/13691
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 0a39efee224e8d4431ae79281ca353a7ba6fdce4)
    
    Change-Id: I8cb4c20eb32c12310f41e38a3f40b132c919bace
    Reviewed-on: https://gerrit.openafs.org/14527
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 56ec046f0137b217a55ff40cc66363c36b7e5c21
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 28 15:03:43 2019 -0500

    FBSD: Set KERNBUILDDIR for --with-bsd-kernel-build
    
    Currently, specifying --with-bsd-kernel-build during configure causes
    us to set BSD_KERNEL_BUILD, which sets KBLD in MakefileProto.FBSD.in,
    but nothing ever uses KBLD. This means that when we use
    --with-bsd-kernel-build, we don't actually build against the
    configuration for that kernel, which can result in a libafs.ko that
    cannot be loaded or causes other errors. Specifically, if trying to
    build for a VIMAGE kernel, the kernel complains when trying to load
    libafs:
    
        [...] kernel: link_elf_obj: symbol in_ifaddrhead undefined
        [...] kernel: linker_load_file: Unsupported file type
    
    The FreeBSD module build system looks for KERNBUILDDIR for an
    alternative build, which it uses to pull in opt_global.h and other
    required pieces from the build tree. So just specify KERNBUILDDIR if
    we have one.
    
    At the same time, avoid setting our default value for BSD_KERNEL_BUILD
    for FBSD when the calculated dir doesn't exist. At least for the
    default GENERIC kernel on FreeBSD 11.2-RELEASE, there may not be a
    build dir on the running machine, and so setting BSD_KERNEL_BUILD to
    the calculated value causes the build to fail when it doesn't exist.
    
    Reviewed-on: https://gerrit.openafs.org/13746
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 8f9c92a888df7b2fd61a3e84aaf1d2c96a8b10dd)
    
    Change-Id: I7afc54121ac3a9d81a7a8005d53eb2ed5df489c1
    Reviewed-on: https://gerrit.openafs.org/14526
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit be3b02e7dee78f492090e89746167116e4f221fd
Author: Tim Creech <tcreech@tcreech.com>
Date:   Sun Mar 5 18:18:01 2017 -0500

    FBSD: Call CURVNET_SET/CURVNET_RESTORE for VIMAGE
    
    In commit 9703b023 (FBSD: VIMAGE support), we changed a couple of our
    variable references to their V_* equivalents, to accommodate kernels
    with VIMAGE turned on. This allows us to build, but causes us to crash
    whenever we hit that code when VIMAGE is enabled, because the relevant
    macros reference 'curvnet', which is NULL outside of networking code.
    
    What we're supposed to do is to set 'curvnet' before entering
    networking code by calling 'CURVNET_SET(xxx)', and reset it afterwards
    by calling 'CURVNET_RESTORE()'. We must make exactly one _RESTORE call
    for each _SET, and they are supposed to be run at the same level of
    scope.
    
    So to avoid the crashes, make the relevant CURVNET_* calls whenever we
    look at networking info. We currently only do this in a few places:
    
    - In afs_SetServerPrefs, to try to detect if a given server address is
      in the same network as one our local interfaces (V_in_ifaddrhead)
    
    - In rxi_GetIFInfo, for some MTU-related info (V_ifnet)
    
    - In rxi_FindIfnet, for some MTU-related info (ifa_ifwithnet)
    
    As for what vnet we actually set 'curvnet' to, we could set it to the
    vnet of the current thread (TD_TO_VNET(curthread)), or we could set it
    to the vnet of an associated network object (a socket, an interface,
    etc). Since all of our network-related code goes through Rx, in this
    commit we set curvnet to the vnet of the Rx socket
    (rx_socket->so_vnet).
    
    Note that VIMAGE is optional in 11-RELEASE, but is turned on by
    default in 12.0-RELEASE. For more information, see:
    https://wiki.freebsd.org/VIMAGE/porting-to-vimage
    
    [adeason@dson.org: Reworded commit message; moved some code around.]
    
    Reviewed-on: https://gerrit.openafs.org/12580
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 1effc3517fdb4b4653d47c59bf67076567209324)
    
    Change-Id: I5fd8b2bf204790b1da6427fe72b8743a7aaa4f13
    Reviewed-on: https://gerrit.openafs.org/14525
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 642f9776c28933ac2769ef9ea67d316dd1c6cff5
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 14 22:53:39 2019 -0500

    FBSD: Remove unnecessary explicit osi_fbsd_alloc
    
    AFS_KALLOC is already defined to be osi_fbsd_alloc on FBSD, so this
    extra #ifdef here is completely unnecessary. Remove it.
    
    Do the same for AFS_KFREE/osi_fbsd_free.
    
    Reviewed-on: https://gerrit.openafs.org/13708
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit ad1fe5e1a825a3b3f88c04fd84613e4105206443)
    
    Change-Id: Ib62b52d040ffd4170a0bb556684244ee1f372401
    Reviewed-on: https://gerrit.openafs.org/14524
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7a5f648e0ac84ecb6321752be5334e16b1b5051e
Author: Andrew Deason <adeason@dson.org>
Date:   Sat Jul 20 23:09:27 2019 -0500

    FBSD: Give 0 'rootrefs' to vflush on unmount
    
    Currently, in afs_unmount, we give vflush a 'rootrefs' arg of 1,
    indicating that we hold 1 reference on the root vnode. But ever since
    commit 6eb1088a (freebsd: properly track vcache references), we drop
    the ref for the root vnode at the beginning of this function.
    
    What happens currently in afs_unmount for a normal successful umount
    is something like this (at least, on FreeBSD 11.2-RELEASE):
    
    - We afs_PutVCache the afs_globalVp vcache, reducing its v_usecount
      and v_holdcnt to 0, and afs_globalVp is set to NULL.
    
    - vflush calls afs_root() to get the root vnode, which sees that
      afs_globalVp is NULL, and so calls afs_GetVCache for the root fid
      and returns it (and sets afs_globalVp to that vcache), with a
      v_usecount of 1.
    
    - vflush tries to vgonel() all of our vnodes, which calls our
      afs_vop_reclaim, which calls afs_FlushVCache(). For the root vnode
      specifically, vflush() sees that v_usecount is nonzero, and so skips
      calling vgonel() at first, but later calls vgone() on it
      specifically because we gave a nonzero 'rootrefs'. The resulting
      afs_FlushVCache() for the root vnode fails, because the root vnode's
      v_usecount is still 1. Since a failure from afs_vop_reclaim would
      cause a panic, we just log a warning and try to continue on anyway.
    
    - vflush() calls vrele() on the root vnode, right before returning.
    
    All of this allows the unmount to proceed, but this means that most of
    afs_FlushVCache() doesn't actually run for the root vcache, and it
    means we always log a warning like this on unmount:
    
        afs_vop_reclaim: afs_FlushVCache failed code 16 [...]
    
    In addition, this means that setting afs_globalVp at the beginning of
    afs_unmount() is largely pointless, since it gets set to a vcache
    again near the beginning of vflush().
    
    To avoid all of this, stop lying to vflush about how many references
    to the root vnode we hold, and just say that we hold 0 references.
    
    Reviewed-on: https://gerrit.openafs.org/13709
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit d13b647aa392e1d802be1023930a8e1a07fb11ab)
    
    Change-Id: I7ca79ee5c10277d6ef94b5f317aa4ba091642ffd
    Reviewed-on: https://gerrit.openafs.org/14523
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a4f5adb0cdc8493603f51422501b4a45b9e26c7f
Author: Tim Creech <tcreech@tcreech.com>
Date:   Sun Mar 5 18:17:23 2017 -0500

    FBSD: Handle F_UNLCK in VOP_ADVLOCK
    
    When a_fl->type is F_UNLCK, FreeBSD gives our VOP_ADVLOCK an a_op of
    F_UNLCK, instead of F_SETLK like we expect. This causes afs_lockctl to
    return EINVAL, since F_UNLCK isn't a normal fcntl lock op, and so
    userspace requests to unlock fcntl-style locks always fail. This can
    be seen, for example, when trying to use sqlite3 to access a database
    that lives in afs.
    
    This F_UNLCK behavior in FreeBSD seems a bit peculiar, but has been
    around effectively forever (since 4.4BSD-Lite). So just work around
    it.
    
    [adeason@dson.org: minor style adjustments and commit message/comment
    rewording.]
    
    Reviewed-on: https://gerrit.openafs.org/12579
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f5acf1b1bfe940faf0a6f4bd11c55d6c90f60242)
    
    Change-Id: I52d0c513aeabd54019fc6d7bb6c3b542e95b2dee
    Reviewed-on: https://gerrit.openafs.org/14522
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 908be3fadb642578f1fb331d229910b386e559c9
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jun 23 17:48:53 2019 -0500

    libafs: Create $(DESTDIR)$(KMODDIR) on FBSD inst
    
    We rely on bsd.kmod.mk for our actual rules during 'make install', but
    that tries to install our kernel module into $(DESTDIR)$(KMODDIR),
    without creating it first. If the user tries to 'make install
    DESTDIR=/some/path' and that path doesn't exist, we will fail with
    something like:
    
    make DESTDIR=/home/adeason/git/destdir single_instdir_libafs
    /usr/bin/install -c -T release -o root -g wheel -m 555   libafs.ko /home/adeason/git/destdir/boot/modules/
    install: /home/adeason/git/destdir/boot/modules/: No such file or directory
    *** Error code 71
    
    To avoid this, add a dependency on the 'install' target which causes
    our target dir to be created.
    
    Reviewed-on: https://gerrit.openafs.org/13653
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 99418024276c94da5982d7dad6126a8d53924d7e)
    
    Change-Id: I439b7b9514b3ab060c887003e0af19557fd2c812
    Reviewed-on: https://gerrit.openafs.org/14521
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8d0651efeb11b248a2d1b9a00b97c2de9724c3d1
Author: Stephan Wiesand <stephan.wiesand@desy.de>
Date:   Fri Mar 22 12:46:17 2019 +0100

    Add param.h files and sysnames for FreeBSD 11.2
    
    Thanks to Måns Nilsson for filing the bug. Note that this change
    differs from the proposed patch in the report, in that it
    doesn't define the 10.4 symbols in the 11.2 param.h files.
    
    FIXES 134850
    
    Reviewed-on: https://gerrit.openafs.org/13534
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    (cherry picked from commit 2ee35afa339731f6a60f1e5e99ccaf63baa6c891)
    
    Change-Id: I6ba8ba41df12f1a5977f5b530aa1353902de5ebe
    Reviewed-on: https://gerrit.openafs.org/14520
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b7bddcf63339a15d0e4c5cd0d56b3b44c428ed54
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Tue May 31 16:23:41 2016 -0400

    SOLARIS: provide cache manager stats via kstat
    
    Provide statistical information via the solaris kstat framework.  Data
    can be examined with the kstat tool or the kstat userspace api.
    
    The kstat module is called openafs. Three kstat names are provided.  The
    "param" name provides cache manager parameters as given by the cmdebug
    -cache program.
    
        # kstat -m openafs -n param
    
    The "cache" name provides cache manager statistics as given by the
    xstats plus some additional cache related stats. The "cache" name also
    provides the libafs kernel module version string and the current local
    cellname.
    
        # kstat -m openafs -n cache
    
    The "rx" name provides general rx statistics as given by rxdebug -rxstat.
    
        # kstat -m openafs -n rx
    
    Reviewed-on: https://gerrit.openafs.org/13170
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 9338cb5fce2e38b864b8f957b6ea4c56c78d20f8)
    
    Change-Id: Ic70d766d7a112d673b6c5898da43b3eea11b1065
    Reviewed-on: https://gerrit.openafs.org/14518
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 4d768b764dbba492805d9e4a4af8474e1f7e0d2e
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Aug 9 17:40:09 2018 -0400

    afs: consolidate duplicated wait-for-cache-drain code
    
    Consolidate duplicated logic into a new routine
    afs_MaybeWaitForCacheDrain().
    
    Reviewed-on: https://gerrit.openafs.org/13278
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 23bd776b0140deb596287869872a41de555ba99a)
    
    Change-Id: I31b04da2170dcdf795b8a50ea7ab78d964eeebf5
    Reviewed-on: https://gerrit.openafs.org/14517
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit afa3802d065375f32876e150588cbce3b88c61e3
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Mon Jun 20 15:29:45 2016 -0400

    afs: more cache truncation stats
    
    Add counters for cache too full and waiting to drain occurrences. These
    will be used in later commits to indicate how often the cache truncation
    is required and how often the cache manager is waiting for cache
    truncation to complete.
    
    Reviewed-on: https://gerrit.openafs.org/13168
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 25792e246362a201743533a970f90dbc77d0ed5c)
    
    Change-Id: I659cce58951c869ce40ff47b13aa79ab33cd26aa
    Reviewed-on: https://gerrit.openafs.org/14516
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit eee6a0cddcd31dafb1c67b3cf909496c232bca09
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Aug 20 16:09:02 2020 -0400

    vol: prevent salvage segfault for orphaned vnode with out-of-range parent
    
    While salvaging a RW volume, salvager may segfault if it encounters an
    orphaned directory with a parent vnode that does not exist.  For
    example, if the large vnode index contains a maximum vnode of 2901, any
    parent vnode encountered that is larger than 2901 will result in an
    out-of-bounds reference to our vnode essence array, leading to a
    segfault or undefined behavior.
    
    Modify the logic to check for out-of-bounds parent vnodes, and log them
    rather than segfaulting.
    
    Reviewed-on: https://gerrit.openafs.org/14385
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 750628da77bb71e24ed3061431bbb913ff8d5f72)
    
    Change-Id: Ib0cabde440d59394704967dd3ab2eb73f07aec22
    Reviewed-on: https://gerrit.openafs.org/14515
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 9e608659f67da53213f376623526638bc10743e5
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Fri Apr 20 00:57:28 2018 -0400

    rx: prevent leakage of non-cached rx_connections (pthread)
    
    The rxi_connectionCache (AFS_PTHREAD_ENV only) allows applications to
    reuse rx_connection structs.  Cached rx_connections are obtained via
    rx_GetCachedConnection and released via rx_ReleaseCachedConnection.
    This feature is used most heavily by libadmin and kauth, but there are
    other users in the tree as well.
    
    For instance, ubikclient routines ubik_ClientInit and ubik_ClientDestroy
    call rx_ReleaseCachedConnections (if AFS_PTHREAD_ENV) when disposing of
    their rx_connections.  Unfortunately, in many cases these rx_connections
    were obtained via rx_NewConnection, _not_ from the cache via
    rx_GetCachedConnection.  In those cases, rx_ReleaseCachedConnection will
    not find the rx_connection in the rxi_connectionCache, and thus it
    returns without doing anything.
    
    Therefore, when ubik_ClientInit is passed an existing ubik_client (for
    re-initialization) that contains rx_connections NOT allocated via
    rx_GetCachedConnection, those connections are not destroyed, but will be
    silently leaked.  Similarly, ubik_ClientDestroy will leak its
    rx_connections when it frees the ubik_client struct.
    
    For example, the fileserver host package calls ubik_ClientInit (via
    hpr_Initialize) and ubik_ClientDestroy (via hpr_End) to manage
    connections to the ptserver.  However, these connections were obtained
    via rx_NewConnection, not rx_GetCachedConnection.  If the fileserver has
    a failed call to the ptserver that sets prfail=1, the next RPC scheduled
    for that client (in CallPreamble) will refresh the thread's ubik_client
    (viced_uclient_key) by calling hprEnd -> ubik_ClientDestroy ->
    rx_ReleaseCachedConnection.  The "released" connections will be leaked.
    
    This problem exists in all versions of OpenAFS going back to IBM 1.0.
    Starting with 1.8.x, many components that were formerly LWP-only are now
    pthreaded and thus susceptible to this leak.
    
    It seems difficult and error-prone to identify all possible code paths
    that may pass a non-cached rx_connection to rx_ReleaseCachedConnection,
    and convert them to obtain connections via rx_GetCachedConnection.
    
    Instead, prevent all existing and future leaks by modifying the connection
    cache to:
    - flag all rx_connections it allocates
    - correctly release any rx_connection it is passed, whether they came
      from the cache or not.
    
    Reviewed-on: https://gerrit.openafs.org/13042
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit bb5397e4c409e3c075ee73d6bf54a3b6eacc0060)
    
    Change-Id: Ia48e29a53a83211c1011eba24c16f78f7253d84b
    Reviewed-on: https://gerrit.openafs.org/14514
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 1e5496856b71dca6cc2fd0e54ea8dea4444e3867
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Apr 30 18:34:28 2018 -0400

    rx: fix out-of-range value for RX_CONN_NAT_PING
    
    Commit 496fb87372555f6acddd4fd88b03c94c85f48511 ("rx: avoid nat ping
    until connection is attached") introduced functionality to defer turning
    on NAT ping for server connections until after reachability had been
    established for the client.
    
    Unfortunately, this feature could never work correctly because it
    assigned an out-of-range flag value of 256 (0x100) for the u_char flags
    field. Instead of calling this out as an error, both gcc and Solaris cc
    elide this flag so that it is never set in
    rx_SetConnSecondsUntilNatPing(), Furthermore, the test in
    rxi_ConnClearAttachWait() will always fail; therefore
    rxi_ScheduleNatKeepAliveEvent is never called after attach wait has
    ended.
    
    Fortunately, this bug is currently moot - not actually exposed in
    OpenAFS. (It was discovered by inspection). This is because there are
    currently no rx_connection objects in the tree that have both NAT ping
    and checkReach (rx_SetCheckReach) enabled. I also searched git history
    and found no time when this bug could ever have been exposed. This does
    raise the question of why the original commit was needed; but instead of
    reverting the original commit, this commit attempts to fix it.
    
    To prevent problems if NAT ping and checkReach are ever both enabled for
    an rx_connection, enlarge the rx_connection flags member so that the
    RX_CONN_NAT_PING value is no longer out of range.
    
    Reviewed-on: https://gerrit.openafs.org/13041
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 55fca11421055d0bcee79f118ea2a035393cc6e5)
    
    Change-Id: I9b02ff06d7bf6ba0dfa30ed5ca17ddb89b517987
    Reviewed-on: https://gerrit.openafs.org/14513
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8453eada315a87ce8fa3cbd54abecb94ed99a947
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Dec 23 12:44:35 2020 -0600

    afs: Fix XBSD check for VNOVAL va_uid
    
    Commit e86eb73e (obsd-vattrs-20040125) introduced an XBSD-specific
    check to detect some unchanged attributes. But the #ifdef for XBSD for
    the va_uid section was added in the middle of an HPUX-specific block
    by mistake.
    
    Move this #ifdef one level higher, so it's actually used on BSD
    platforms.
    
    Reviewed-on: https://gerrit.openafs.org/14473
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Tim Creech <tcreech@tcreech.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit cd35aa9e2aec16d622177eeea1e1b3ec8aacdd45)
    
    Change-Id: I6a840cffc1e3dfc6df1237261aa3a21bb3b73fbc
    Reviewed-on: https://gerrit.openafs.org/14512
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ee53dd3bc087a05e22fc4111297a51ddb30013f0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jan 22 07:57:55 2021 -0700

    Linux 5.11: Test 32bit compat with in_compat_syscall
    
    Linux 5.11 removed the TIF_IA32 thread flag with commit:
      x86: Reclaim TIF_IA32 and TIF_X32 (8d71d2bf6efec)
    
    The flag TIF_IA32 was being used by openafs to determine if the task was
    handling a syscall request from a 32 bit process.  Building against a
    Linux 5.11 kernel results in a build failure as TIF_IA32 is undefined.
    
    The function 'in_compat_syscall' was introduced in Linux 4.6 as
    the preferred method to determine if a syscall needed to handle a
    compatible call (e.g. 32bit application).
    
    To resolve the build problem, use 'in_compat_syscall' if present (Linux
    4.6 and later) to determine if the syscall needs to handle a
    compatibility mode call.
    
    Add autoconf check for in_compat_syscall.
    
    Notes about in_compat_syscall:
    
    In Linux 4.6 'in_compat_syscall' was defined for all architectures with
    a generic return of 'is_compat_task', but allows architecture specific
    overriding implementations (x86 and sparc).
    
    At 4.6 (and later), the function 'is_compat_task' is defined only for
    the following architectures to return:
    
    Arch              Returns
    =======           ==============================
    arm64             test_thread_flag(TIF_32BIT);
    mips              test_thread_flag(TIF_32BIT_ADDR)
    parisc            test_ti_thread_flag(task_thread_info(t), TIF_32BIT)
    powerpc           is_32bit_task()
    s390              test_thread_flag(TIF_31BIT)
    sparc             test_thread_flag(TIF_32BIT)
    
    If the Linux kernel is not built with compat mode, is_compat_task and
    in_compat_syscall is set to always return 0
    
    Linux commit that introduced in_compat_syscall:
      compat: add in_compat_syscall to ask whether we're in a compat syscall
      (5180e3e24fd3e8e7)
    
    Reviewed-on: https://gerrit.openafs.org/14499
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 78ef922612bef5f5fd6904896e84b9d2ea802404)
    
    Change-Id: I4eca62f19ae58fd830915feff5098cec2825f099
    Reviewed-on: https://gerrit.openafs.org/14511
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 4ad1057ab8fd206c9fa8d5e3bdde4f1a8417afdb
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jan 29 11:32:36 2021 -0700

    Linux: Refactor test for 32bit compat
    
    Refactor the preprocessor checks for determining the method to test for
    32bit compatibility (64bit kernel performing work for a 32bit task) into
    a common inline function, 'afs_in_compat_syscall' that is defined in
    LINUX/osi_machdep.h.  Update osi_ioctl.c and afs_syscall.c to use
    afs_in_compat_syscall.
    
    Add include afs/sysincludes into osi_machdep.h to ensure linux/compat.h
    is pulled for the functions called in afs_in_compat_syscall.
    
    Reviewed-on: https://gerrit.openafs.org/14500
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 32cc6b0796495e596262d84c428172a511f757c4)
    
    Change-Id: I746e5777737d49381c4a74627b79d2a61cbd4f8e
    Reviewed-on: https://gerrit.openafs.org/14510
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit aaa7043a154d35838e65bc28473355c452339bcc
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jan 28 16:59:47 2021 -0600

    LINUX: Fix includes for fatal_signal_pending test
    
    Commit 8b6ae289 (LINUX: Avoid lookup ENOENT on fatal signals) added a
    configure test for fatal_signal_pending(). However, this check fails
    incorrectly ever since Linux 4.11, because fatal_signal_pending() was moved
    from linux/sched.h to linux/sched/signal.h in Linux commit 2a1f062a
    (sched/headers: Move signal wakeup [...]). Fix this by including
    linux/sched/signal.h if we have it during the configure test.
    
    A false negative on this configure test doesn't break the build, but
    it disables one of our safeguards preventing incorrect negative
    dentries at runtime. The function fatal_signal_pending() hasn't
    changed in quite some time (except for what header it lives in); it
    was introduced in Linux 2.6.25 via Linux commit f776d12d (Add
    fatal_signal_pending). So to try to avoid this mistake again in the
    future, make it so a missing fatal_signal_pending() breaks the build
    if we're on Linux 2.6.25+.
    
    Reviewed-on: https://gerrit.openafs.org/14508
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 0c1465e4f3310daa54f1e799f76237604222666d)
    
    Change-Id: I1334c060f8ab5733461ebf7c191dffa7be830021
    Reviewed-on: https://gerrit.openafs.org/14509
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 25d6d88dec67b3ab2a04a1f94baf04291fdb63d6
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Sep 19 12:18:08 2019 -0500

    rx: Avoid new server calls for big-seq DATA pkts
    
    We currently never open our receive window to more than 32 packets. If
    we received a DATA packet for an unrecognized call with a seq of 33 or
    more, the packet is almost certainly from a previously-running call
    that we were restarted during.
    
    As described in commit 7b204946 (rx: Avoid lastReceiveTime update for
    invalid ACKs) and commit "rx: Avoid new server calls for non-DATA
    packets", clients can get confused when we respond to calls in these
    situations, so drop the packets instead.
    
    Reviewed-on: https://gerrit.openafs.org/13876
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a36832e2d891caab8644a3b4641c7c94fab4105f)
    
    Change-Id: I72f903b81a205bb3e64862da03f9c1c76cc37b75
    Reviewed-on: https://gerrit.openafs.org/14507
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5bbbbe37ac7ffece710f55c471a34e5fc89543a8
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Thu Aug 8 18:18:22 2019 -0400

    rx: Avoid new server calls for non-DATA packets
    
    Normally, a client starts a new Rx call by sending DATA packets for
    that call to a server, and rxi_ReceiveServerCall on the server creates
    a new call struct for that call (since we don't recognize it as an
    existing call).
    
    Under certain circumstances, it's possible for a server to see a
    non-DATA packet as the first packet for a call, and currently
    rxi_ReceiveServerCall will create a new server call for any packet
    type. The call cannot actually proceed until the server receives data
    from the client (and goes through the challenge/response auth
    handshake, if needed), but usually this is harmless, since the
    existence of any packets for a particular call channel indicate that
    the client is trying to run such a call. The server will respond to
    the client with ACKs to indicate that it is missing the needed DATA
    packet(s), and the client will send them and the call can proceed.
    
    However, if a call is in the middle of running when the server is
    restarted, the client may be sending ACKs for a pre-existing call that
    the server doesn't know about. In this case, the server generates ACKs
    that indicate the server has not received any DATA packets, which may
    appear to violate the protocol, depending on the prior state of the
    call (e.g. the server appears to try to move the window backwards).
    
    Clients should be able to detect this and kill the call, but many do
    not. For many OpenAFS releases before commit 7b204946 (rx: Avoid
    lastReceiveTime update for invalid ACKs), the client will get confused
    in this situation and will keep the call open forever, never making
    progress.
    
    There isn't any benefit to creating a new server call in these
    situations, so just ignore non-DATA packets for unrecognized calls, to
    avoid stalled calls from such clients. Those clients will not get a
    response from the server, and so the call will eventually die from the
    normal Rx call timeout.
    
    Reviewed-on: https://gerrit.openafs.org/13758
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 3f9a08db86f951df3f6f69f1143f17dd7b43b150)
    
    Change-Id: Iaf8ee360f8aa634b5a7728866e41de267389e1f3
    Reviewed-on: https://gerrit.openafs.org/14506
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit d5743ef92a92fe298d68ae4095bf4d4515971f7f
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Aug 27 22:58:23 2019 -0500

    rx: Avoid lastReceiveTime update for invalid ACKs
    
    Currently, we ignore ACK packets in a few cases:
    
    - If the ACK appears to move the window backwards (if firstPacket is
      smaller than call->tfirst).
    
    - If the ACK appears to have been received out of order (if
      previousPacket is smaller than call->tprev).
    
    - If the ACK packet appears truncated.
    
    In all of these cases, we ignore the ACK packet completely in our ACK
    processing code (rxi_ReceiveAckPacket), but we still process the
    packet at higher levels (rxi_ReceivePacket). Notably, this means we
    update call->lastReceiveTime after rxi_ReceiveAckPacket returns, even
    for ACK packets we haven't really looked at.
    
    Normally this does not cause any noticeable problems, because such
    packets should either never be encountered, or only consist of a small
    number of packets that are mixed in with valid packets.
    
    However, if our peer is a server, and it is restarted in the middle of
    a call, our peer may exclusively send us packets that fall into the
    above categories. (This does not happen if our peer is a client,
    because clients just ignore packets for calls they do not recognize.)
    For example:
    
    Consider a call where a client is sending data to a server, and the
    server restarts after the client has sent a DATA packet with sequence
    number 1000. The server may then start responding to the client with ACKs
    with firstPacket set to 1, since the restarted server has no knowledge
    of the call's state.
    
    In this case, a firstPacket of 1 is well below where our window was,
    so all of the ACKs from the server are ignored. But we keep updating
    call->lastReceiveTime for all of these packets, and so the call stays
    alive forever until an idle-dead or hard-dead timeout activates (if
    any are set).
    
    As another example, consider the case where a client is sending data
    to a server, and the server receives a full window of packets (say, 16
    packets), has not yet passed any data to the application yet, and the
    server restarts. The restarted server then starts responding to the
    client with ACKs with firstPacket set to 1, and previousPacket set to
    0. We also ignore all of the ACKs from the server in this case,
    because even though firstPacket looks sane, it looks like
    previousPacket has gone backwards. We still update
    call->lastReceiveTime for each ignored ACK we get, keeping the call
    alive.
    
    Before commit 4e71409f (Rx: Reject out of order ACK packets) was
    introduced in 1.6.0, neither of these issues could occur. That commit
    introduced the issue specifically if previousPacket goes backwards;
    that is, if the server restarts before firstPacket moves forwards.
    
    Commit 8d359e6d (rx: Remove duplicate out of order ACK check) in 1.8.0
    introduced the issue when 'firstPacket' goes backwards, since
    previously the FIRSTACKOFFSET-based check caused us to ignore those
    packets without updating call->lastReceiveTime. That is, if the server
    restarts after firstPacket moves forwards.
    
    In this commit, we still ignore packets in the above cases, but we
    also avoid updating lastReceiveTime when we update such packets, to
    make sure that we do not keep a call alive solely from receiving these
    invalid packets.
    
    Alternatively, we could change our logic to immediately abort calls
    where firstPacket moves backwards (since this violates the Rx
    protocol), or to not ignore some packets where previousPacket goes
    backwards (since these calls may be recoverable). And we could also
    skip updating lastReceiveTime for invalid packets of other types. But
    for now, this commit just avoids updating lastReceiveTime for invalid
    ACK packets, in order to just try to restore our behavior before
    1.6.0, while still retaining the benefits of ignoring out-of-order
    ACKs. Further changes in this area can potentially be handled
    separately by future commits.
    
    Also increment the spuriousPacketsRead counter for packets that we
    ignore in this way (which we used to do for some packets before commit
    8d359e6d), so we are not entirely silent about ignoring them.
    
    Written in collaboration with mvitale@sinenomine.net.
    
    Reviewed-on: https://gerrit.openafs.org/13875
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7b204946010673506e0f74991f59a0865292199c)
    
    Change-Id: I8e0299bdeedb005fe49a2d1c4a00a21301fbbb04
    Reviewed-on: https://gerrit.openafs.org/14505
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 49975e8b07c340cb675445015f41474dc39cd535
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Aug 28 17:12:53 2019 -0500

    rx: Introduce ack_is_valid
    
    Take some of our existing logic for ignoring invalid ACK packets and
    split it out into a separate function, ack_is_valid. This just makes
    it easier to add more complex logic in here and write longer comments
    explaining the decisions.
    
    Note that the bug mentioned regarding the previousPacket field was
    introduced in IBM AFS 3.5, and was fixed in OpenAFS in commit bbf92017
    (rx: rxi_ReceiveDataPacket do not set rprev on drop), included in
    OpenAFS 1.6.23.
    
    This commit incurs no functional change; it is just code
    reorganization.
    
    Reviewed-on: https://gerrit.openafs.org/13874
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f6490629e1239c412002f316804c656c9be61400)
    
    Change-Id: I5d0ee9b7fc56659e445705a01d5d90141eb8cfe2
    Reviewed-on: https://gerrit.openafs.org/14504
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c32ad5017d48640ea7f6430f844324b3d7fd90b5
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Nov 2 13:52:25 2020 -0600

    rx: For AFS_RXERRQ_ENV, retry sendmsg on error
    
    When AFS_RXERRQ_ENV is defined, we currently end up doing something
    like this for our sendmsg abstractions:
    
        if (sendmsg(...) < 0) {
            while (rxi_HandleSocketError(sock))
                ;
            return error;
        }
        return success;
    
    This means that when sendmsg() returns an error, we process the socket
    error queue before returning an error.
    
    The problem with this is that when we receive an ICMP error on our
    socket, it creates a pending socket error that is returned for any
    operation on the socket. So, if we receive an ICMP error after trying
    to contact any peer, sendmsg() could return an error when trying to
    send for any other peer. Even though there is no issue preventing us
    from sending the packet, we'll fail to actually send the packet
    because sendmsg() returned an error. This effectively causes an extra
    outgoing packet drop, possibly delaying the related RPC.
    
    To avoid this, change Rx to retry the sendmsg call when it returns an
    error, since the error may be due to an unrelated ICMP error.
    
    To avoid needing to implement this retry loop in multiple places, move
    around our sendmsg code for AFS_RXERRQ_ENV, so that the higher-level
    function rxi_NetSend performs the retry and checks for socket errors
    (instead of the lower-level rxi_Sendmsg or osi_NetSend). Also change
    our functions to process socket errors to be more consistent between
    kernel and userspace: now we always have rxi_HandleSocketErrors, which
    runs a loop around the platform-specific osi_HandleSocketError.
    
    With this commit, osi_HandleSocketError is now required to be
    implemented when AFS_RXERRQ_ENV is defined. We hadn't been
    implementing this for UKERNEL, so just turn off AFS_RXERRQ_ENV for
    UKERNEL.
    
    Thanks to mbarbosa@sinenomine.net for discovering and providing
    information about the relevant issue.
    
    Reviewed-on: https://gerrit.openafs.org/14424
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 5c9234694543f206174d30e21886286d419fd8df)
    
    Change-Id: I1b21ba4d2b98abae240cb683d6061462db028431
    Reviewed-on: https://gerrit.openafs.org/14503
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a6173b39a874d7cce3a826d7b4dce58ee6a48983
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Nov 2 13:16:41 2020 -0600

    rx: Save errno in pthread rxi_Sendmsg
    
    Currently, our pthread version of rxi_Sendmsg uses 'errno' in some
    logic if sendmsg fails, but we do so after calling functions that
    might alter errno (e.g. fflush).
    
    To make sure we get the correct errno value, save the value of errno
    right after sendmsg returns an error. Reorganize this function a bit
    to help make the logic easier to follow.
    
    Reviewed-on: https://gerrit.openafs.org/14423
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit eff7fa4b2eb9a3001dc18dca157ccbd5f19f89b6)
    
    Change-Id: Ie761bf8fbf930718d933fdc2d0ad6961b2660607
    Reviewed-on: https://gerrit.openafs.org/14502
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5b6ea9e9bd37d17b1cf29bb8ef377091ffccae69
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jan 9 12:38:45 2020 -0600

    aklog: Make dummy write AIX-specific
    
    This weird write() call exists to work around some old AIX-specific
    bug. The ifdef looks like it is intended to restrict this to pre-5
    AIX, but it also turns this on for all non-AIX platforms.
    
    Make this area AIX-specific, to avoid this weird write on other
    platforms that have nothing to do with the relevant workaround.
    
    Reviewed-on: https://gerrit.openafs.org/14022
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 6ee2d6de7d87c93c849f3afbe4326906e4c10852)
    
    Change-Id: Iaa84f1c1df57f9b0749c2577e496fbf8740e48c1
    Reviewed-on: https://gerrit.openafs.org/14483
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7d7b3f06bb72aa2969b164ff71d61d723628f52c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Aug 28 17:26:41 2019 +0530

    aklog: avoid infinite lifetime tokens by default
    
    Currently we get tokens for infinite lifetime using aklog impersonate
    feature. Based on inputs from Ben, this was done for server to server
    tickets to be valid forever.  However on 1.8.x we have other
    mechanisms that were usable for server-to-server authentication with
    strong enctypes, so we do not need to provide user level akimpersonate
    to generate tokens for infinite lifetime. For this we have added new
    option -token-lifetime <hrs>, this can take values from 0 to 720
    hours. If 0 is specified it means tokens will have infinite lifetime.
    By default 10 hours will be token lifetime for akimpersonate tokens.
    
    Reviewed-on: https://gerrit.openafs.org/13828
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 1de602aaada15df1008140784092c2a76a2613a1)
    
    Change-Id: I032431ab1b8b174ac8d80322b688dc2a7285b8fa
    Reviewed-on: https://gerrit.openafs.org/14482
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 97400f8a8c1b5756f67cf5434a65faa9a5d3d22b
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Aug 28 17:04:31 2019 +0530

    aklog: use any enctype in get_credv5
    
    We currently always pass DES as the requested enctype to
    get_credv5_akimpersonate, but this means we will fail to use our
    service princ if we're using another enctype (say, AES) with rxkad-k5.
    To allow this to work with any enctype, just don't pass any requested
    enctypes, and just use the enctype inside the 'entry' returned to us
    from krb5_kt_get_entry.
    
    Remove all of the logic associated with the now-unused
    "allowed_enctypes" argument. Also remove the logic handling the case
    where "service_principal" is NULL (since no callers pass a NULL
    service_principal), to make it easier to take out the allowed_enctypes
    related code.
    
    Reviewed-on: https://gerrit.openafs.org/13827
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 276bd5c7f8a2ec7673d2ad084566203eb2055938)
    
    Change-Id: Ia4b2cab3b2cd81214683dc00d7092a302d5af1bd
    Reviewed-on: https://gerrit.openafs.org/14481
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 93f21573642f01e906f6711bae13006cc708f0d3
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Aug 28 16:43:35 2019 +0530

    aklog: retry getting tokens for KRB5_KT_NOTFOUND error
    
    If we're creating tokens with -keytab and our AFS service principal is
    afs@<cellname>, we'll first try creating tokens with
    afs/<cellname>@<cellname> and krb5_kt_get_entry will fail with
    KRB5_KT_NOTFOUND. Since we do not retry for KRB5_KT_NOTFOUND error, we
    will not get tokens. So in order to get tokens for principal
    afs@<cellname> we should retry for KRB5_KT_NOTFOUND error. Thanks to
    jpjanosi@us.ibm.com for finding this issue and suggesting a fix.
    
    Reviewed-on: https://gerrit.openafs.org/13826
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 7a13bce2513baf5a3a61db94f3d88232241cea5b)
    
    Change-Id: I4f4dfb4c1372aef88a938d1b96d012a3f6bb4218
    Reviewed-on: https://gerrit.openafs.org/14480
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 26c1720b2c18cdda1807424d96547342248aa64c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Aug 28 16:25:49 2019 +0530

    aklog: Use HAVE_ENCODE_KRB5_ENC_TKT_PART for aklog impersonate
    
    In get_credv5_akimpersonate we use HAVE_ENCODE_KRB5_ENC_TKT which is not
    defined, due to this we always return -1 from this routine for non
    Heimdal case. We have a another define i.e
    HAVE_ENCODE_KRB5_ENC_TKT_PART which is defined if
    encode_krb5_enc_tkt_part function is present. In current code
    encode_krb5_enc_tkt_part is called from krb5_encrypt_tkt_part and
    krb5_encrypt_tkt_part is called from get_credv5_akimpersonate for non
    Heimdal case. So we should change HAVE_ENCODE_KRB5_ENC_TKT to
    HAVE_ENCODE_KRB5_ENC_TKT_PART.
    Also while we're here, add a declaration for the internal function
    encode_krb5_ticket, so we can build this newly-enabled code without
    warnings.
    
    Reviewed-on: https://gerrit.openafs.org/13825
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 6559297610de0f71c9050f3582d4d146e0cc1f3c)
    
    Change-Id: Ia89cdbf23160c71e5b65b8220e1c1f73f1055064
    Reviewed-on: https://gerrit.openafs.org/14479
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit e262f3a22d209b147d56e302634f95ffc37b007b
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Sat Aug 10 02:54:38 2019 +0530

    aklog: Free client/server princs in get_credv5
    
    Inside get_credv5, client_principal is static so the first time
    get_credv5 runs we'll allocate memory for it, and on subsequent calls
    we'll reuse the same value.
    
    However, if we call get_credv5_akimpersonate, we'll free
    client_principal and never change what client_principal points to. If we
    need to call get_credv5 again (because we need to retry getting creds),
    we'll reuse the old value for client_principal, but since it points to
    free memory we'll segfault or cause other problems.
    
    To avoid this, change get_credv5 so we allocate the client and server
    principals on each invocation of get_credv5 and free them before
    returning from get_credv5. Since we free the client and server
    principals inside get_credv5, remove freeing the client and server
    principals inside get_credv5_akimpersonate.
    
    Reviewed-on: https://gerrit.openafs.org/13761
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit ab8b28540ef17d67db02d5dbcb7585443c164e45)
    
    Change-Id: I818202660be4522bd49bf207c59d202ed8adf88d
    Reviewed-on: https://gerrit.openafs.org/14478
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8e98d9c1cad3afef5508dcc16cc04946be43d9b8
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Sat Aug 10 02:41:01 2019 +0530

    aklog: free kbr5_creds before returning from rxkad_get_token
    
    rxkad_get_ticket allocates 'v5cred' which should be freed when we
    return from rxkad_get_token.
    
    Reviewed-on: https://gerrit.openafs.org/13760
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 130a92214cc0b9a8f4ea24a3dcd3ed04575e3c4e)
    
    Change-Id: I02720f37c71ee56b4bd3d79d5f3e06c3ee647c9b
    Reviewed-on: https://gerrit.openafs.org/14477
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 563f5b2915a4a43b2642dba8287b3d6d36d5b3c8
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Sat Jan 9 12:47:09 2021 -0600

    WINNT: Restore missing '#ifdef PC'
    
    Commit 339167ef (Remove dead code) meant to remove the '#ifdef notdef'
    block in here, but we accidentally also removed the subsequent '#ifdef
    PC'.
    
    This file may not be very important, since WINNT still builds with
    this mistake, but an unbalanced #ifdef is potentially super confusing,
    so fix it.
    
    Reviewed-on: https://gerrit.openafs.org/14487
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 2971dcb3b4da04fff3f4bd9c3d3e3f0ab7a94cae)
    
    Change-Id: I273ad30d38d7a41e7ec662994d91e084c24194bb
    Reviewed-on: https://gerrit.openafs.org/14490
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 734c7650597b461848829f0706b6a5be29e9fbb9
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Jul 10 15:14:28 2019 -0500

    Remove dead code
    
    There is a perhaps-surprisingly large amount of code disabled behind
    directives like '#if 0', '#ifdef notdef', and '#ifdef notyet'. At
    best, this code is clutter, and at worst some of it is
    confusing/outdated, and/or confusingly nested inside other
    preprocessor conditionals. Sometimes this disabled code shows up when
    grepping the tree, and causes a nuisance when refactoring related
    areas of code.
    
    Get rid of all of it. If anyone ever wants this code back, it can
    always be restored by reverting portions of this commit.
    
    Also delete some comments that clearly refer to the disabled code, and
    in some cases, adjust the adjacent comments to make sense accordingly.
    
    This commit doesn't touch any files in src/external/.
    
    Reviewed-on: https://gerrit.openafs.org/13683
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 339167ef1fda899655969f4572ff95271dfdb7cf)
    
    Change-Id: I440b01de0fdb0ef2602557bf3fa35dcdf9a22cdc
    Reviewed-on: https://gerrit.openafs.org/14476
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7e42148ee75ff523cd232658fd3f46945f5920ce
Merge: 5004f88 06b800f
Author: Benjamin Kaduk <kaduk@mit.edu>
Date:   Thu Jan 14 14:24:38 2021 -0800

    Merge branch 'openafs-stable-1_8_7-branch' into openafs-stable-1_8_7
    
    Record the history of the 1.8.7 emergency patch release.
    Resolve the nominal conflict in configure.ac due to 1.8.7 bumping
    the version and openafs-stable-1_8_x removing the LINUX_PKGREL variable.
    
    Change-Id: Ifa719bcec3948b2634841fba90e835f9db088dd6

commit 06b800f6f1022fa4b86eb9023b75028f2e2cfeab
Author: Benjamin Kaduk <kaduk@mit.edu>
Date:   Thu Jan 14 13:08:41 2021 -0800

    Make OpenAFS 1.8.7
    
    Update version strings for the 1.8.7 emergency patch release.
    
    Change-Id: I665bedad864b1c2cbbe55978d6b06e917ed26faa

commit f3b5c62660a48f693897d2faa1cecfd1c10307de
Author: Benjamin Kaduk <kaduk@mit.edu>
Date:   Thu Jan 14 13:06:18 2021 -0800

    Update NEWS for 1.8.7
    
    Add the release notes for the 1.8.7 emergency patch release.
    
    Change-Id: I813f11e4e72c12cb927f66472b099febbf3d899f

commit 81a3600bfdcc122d43c75720e83317dcc2a9e6a1
Author: Benjamin Kaduk <kaduk@mit.edu>
Date:   Thu Jan 14 10:20:59 2021 -0800

    Remove overflow check from update_nextCid
    
    The rx_nextCid global has been an unsigned type since
    http://gerrit.openafs.org/11106 (which was actually merged before
    the refactoring of overflow check to avoid signed integer overflow)
    and thus there is no need to avoid signed overflow.  The per-connection
    cid has been unsigned since the IBM import.
    
    The natural unsigned behavior on overflow of wrapping is the desired
    behvaior here, so just remove the extra logic and always increment.
    
    Reviewed-on: https://gerrit.openafs.org/14496
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13)
    
    Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d
    Reviewed-on: https://gerrit.openafs.org/14497
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8)

commit 6f898c4c711d0aff7ea452670164802b5e423c18
Author: Jeffrey Altman <jaltman@auristor.com>
Date:   Thu Jan 14 09:57:13 2021 -0500

    rx: update_nextCid overflow handling is broken
    
    The overflow handling in update_nextCid() produces a rx_nextCid
    value of 0x80000001 which itself is out of the valid range.   When
    used to construct the first call of a new connection the connection
    id for the call becomes 0x80000002, and all subsequent connections
    also trigger the overflow handling and thus also receive connection
    id 0x80000002.
    
    If the same connection id is used for multiple connections from
    the same endpoint the accepting rx peer will be very confused.
    
    When authenticated connections are used, the CHALLENGE/RESPONSE
    will fail because of a mismatch in the connection's callNumber
    array.
    
    If an initiator makes only a single connection to a given rx peer,
    that connection would succeed, but once multiple connections are
    initiated all communication from a broken initiator to any rx peer
    will fail.
    
    The incorrect overflow calculation was introduced by
    39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
    generation into the rx core").
    
    This change corrects the overflow value to become
    
      1 << RX_CIDSHIFT
    
    Reviewed-on: https://gerrit.openafs.org/14492
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 2c0a3901cbfcb231b7b67eb0899a3133516f33c8)
    
    Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d
    Reviewed-on: https://gerrit.openafs.org/14494
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7)

commit 54c56dfa423bac14db117f5ec641ebe0eda705e3
Author: Jeffrey Altman <jaltman@auristor.com>
Date:   Thu Jan 14 09:41:39 2021 -0500

    rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid
    
    39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
    generation into the rx core") introduced the use of RAND_bytes()
    to generate the initial 'rx_nextCid' but failed to remove the
    
      rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT;
    
    assignment inherited from IBM/Transarc.
    
    At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation
    overflows the value CID range.   This triggers broken overflow
    logic in update_nextCid().
    
    Reviewed-on: https://gerrit.openafs.org/14491
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473)
    
    Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8
    Reviewed-on: https://gerrit.openafs.org/14493
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit a41fe24be574f35ca852fc3ea9750e370cdb71d0)

commit 5004f888e32e8274fcd8a28a7bff6aa3a79f41c8
Author: Benjamin Kaduk <kaduk@mit.edu>
Date:   Thu Jan 14 10:20:59 2021 -0800

    Remove overflow check from update_nextCid
    
    The rx_nextCid global has been an unsigned type since
    http://gerrit.openafs.org/11106 (which was actually merged before
    the refactoring of overflow check to avoid signed integer overflow)
    and thus there is no need to avoid signed overflow.  The per-connection
    cid has been unsigned since the IBM import.
    
    The natural unsigned behavior on overflow of wrapping is the desired
    behvaior here, so just remove the extra logic and always increment.
    
    Reviewed-on: https://gerrit.openafs.org/14496
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 43ef1f2a5d80aa1c3f5b4831ada8e776ac0c7d13)
    
    Change-Id: I64fabe5229039f7af040902ed2e6f03dba7bc14d
    Reviewed-on: https://gerrit.openafs.org/14497
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>

commit f5ed8c2fac4c94914099881250f5f2e893f3f9f7
Author: Jeffrey Altman <jaltman@auristor.com>
Date:   Thu Jan 14 09:57:13 2021 -0500

    rx: update_nextCid overflow handling is broken
    
    The overflow handling in update_nextCid() produces a rx_nextCid
    value of 0x80000001 which itself is out of the valid range.   When
    used to construct the first call of a new connection the connection
    id for the call becomes 0x80000002, and all subsequent connections
    also trigger the overflow handling and thus also receive connection
    id 0x80000002.
    
    If the same connection id is used for multiple connections from
    the same endpoint the accepting rx peer will be very confused.
    
    When authenticated connections are used, the CHALLENGE/RESPONSE
    will fail because of a mismatch in the connection's callNumber
    array.
    
    If an initiator makes only a single connection to a given rx peer,
    that connection would succeed, but once multiple connections are
    initiated all communication from a broken initiator to any rx peer
    will fail.
    
    The incorrect overflow calculation was introduced by
    39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
    generation into the rx core").
    
    This change corrects the overflow value to become
    
      1 << RX_CIDSHIFT
    
    Reviewed-on: https://gerrit.openafs.org/14492
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 2c0a3901cbfcb231b7b67eb0899a3133516f33c8)
    
    Change-Id: I74d70706ddf99022bed639891cb610fba9ef863d
    Reviewed-on: https://gerrit.openafs.org/14494
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>

commit a41fe24be574f35ca852fc3ea9750e370cdb71d0
Author: Jeffrey Altman <jaltman@auristor.com>
Date:   Thu Jan 14 09:41:39 2021 -0500

    rx: rx_InitHost do not overwrite RAND_bytes rx_nextCid
    
    39b165cdda941181845022c183fea1c7af7e4356 ("Move epoch and cid
    generation into the rx core") introduced the use of RAND_bytes()
    to generate the initial 'rx_nextCid' but failed to remove the
    
      rx_nextCid = ((tv.tv_sec ^ tv.tv_usec) << RX_CIDSHIFT;
    
    assignment inherited from IBM/Transarc.
    
    At Thu, 14 Jan 2021 08:25:36 GMT the IBM inherited calculation
    overflows the value CID range.   This triggers broken overflow
    logic in update_nextCid().
    
    Reviewed-on: https://gerrit.openafs.org/14491
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a3bc7ff1501d51ceb3b39d9caed62c530a804473)
    
    Change-Id: If5f7d4ba1cacc6978c83fd512653fbaa0c1559d8
    Reviewed-on: https://gerrit.openafs.org/14493
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>

commit b65b33da4e65e2c981ce264ef4fa4e3e4c94b732
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Mon Aug 17 15:44:55 2020 -0400

    vldb_check: Check for volume lock inconsistencies
    
    Verify the a lock timestamp is set if, and only if, a lock volume
    operation flag is also set.
    
    When running vldb_check with the -fix option, fix the inconsistent
    entries by setting the lock timestamp to the current time if a lock flag
    is set, or by setting the VLOP_DELETE flag if the lock timestamp is set
    but no lock flags are set. (The VLOP_DELETE flag is the flag set by the
    'vos lock command, and is shown in vos output as "delete/misc".)
    
    Volume lock fields can be put into an inconsistent state, at least, by
    interupted vos rename operations, due to bugs in vos rename. When the
    volume lock timestamp and lock flags are in this inconsistent state, the
    volume is locked, but that is not indicated by 'vos listvldb'. The
    volume can be unlocked by issuing 'vos unlock'.
    
    Reviewed-on: https://gerrit.openafs.org/14307
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 4c33820525af510a8a937289005e39d5b6683b19)
    
    Change-Id: Ia894139145d92948b2af43bd115792556131cd5a
    Reviewed-on: https://gerrit.openafs.org/14450
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 37187ba29454cba5a79eebff6251d6ff145907cf
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon May 18 12:09:38 2020 -0500

    auth: Close fd on SetExtendedCellInfo write error
    
    Currently, and since OpenAFS 1.0, if write() fails here, we leak the
    file descriptor. A write() failure should be very unlikely, but close
    the fd to make sure we avoid the leak.
    
    Reviewed-on: https://gerrit.openafs.org/14213
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit c81579dc7b0c0ac6bc34f63384d705a4445c2bbd)
    
    Change-Id: I4dd96cca2fd9c01390fb508ab12d507ab1a56c8b
    Reviewed-on: https://gerrit.openafs.org/14461
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b201d2a3a97830d34ea5b76c9c2d5d3adc1a54a6
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jul 26 15:48:00 2018 -0500

    Remove DUX/OSF code
    
    Remove code for DUX/OSF platforms. DUX code was removed from the
    libafs client in commit 392dcf67 ("Complete removal of DUX client
    code") and the alpha_dux* param files were removed in dc4d9d64 ("afs:
    Remove AFS_BOZONLOCK_ENV"). This code has always been disabled since
    those commits, so remove any code referencing AFS_DUX*_ENV,
    AFS_OSF_ENV, and related symbols.
    
    Reviewed-on: https://gerrit.openafs.org/13260
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 6534b10a4180ec10bceebbc11405718e7969fa21)
    
    Change-Id: I632636fe6c5111b60c5b586c346ecc10ccfa8f3c
    Reviewed-on: https://gerrit.openafs.org/14452
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c55607d732a65f8acb1dfc6bf93aee0f4409cecf
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Oct 26 12:35:32 2020 -0500

    LINUX: Return errors in our d_revalidate
    
    In our d_revalidate callback (afs_linux_dentry_revalidate), we
    currently 'goto bad_dentry' when we encounter any error. This can
    happen if we can't allocate memory or some other internal errors, or
    if the relevant afs_lookup call fails just due to plain network
    errors.
    
    For any of these cases, we'll treat the dentry as if it's no longer
    valid, so we'll return '0' and call d_invalidate() on the dentry.
    However, the behavior of d_invalidate changed, as mentioned in commit
    afbc199f1 (LINUX: Avoid d_invalidate() during
    afs_ShakeLooseVCaches()). After a certain point in the Linux kernel,
    d_invalidate() will also effectively d_drop() the given dentry,
    unhashing it. This can cause getcwd() calls to fail with ENOENT for
    those directories (as mentioned in afbc199f1), and can cause
    bind-mount calls to fail similarly during a small window.
    
    To avoid all of this, when we encounter an error that prevents us from
    checking if the dentry is valid or not, we need to return an error,
    instead of saying 'yes' or 'no'. So, change
    afs_linux_dentry_revalidate to jump to the 'done' label when we
    encounter such errors, and avoid calling d_drop/d_invalidate in such
    cases. This also lets us remove the 'lookup_good' variable and
    consolidate some of the related logic.
    
    Important note: in older Linux kernels, d_revalidate cannot return
    errors; callers just interpreted its return value as either 'valid'
    (non-zero) or 'not valid' (zero). The treatment of negative values as
    errors was introduced in Linux commit
    bcdc5e019d9f525a9f181a7de642d3a9c27c7610, which was included in
    2.6.19. This is very old, but technically still above our stated
    requirements for the Linux kernel, so try to handle this case, by
    jumping to 'bad_dentry' still for those old kernels. Just do this with
    a version check, since no configure check can detect this (no function
    signatures changed), and the only Linux versions that are a concern
    are quite old.
    
    Reviewed-on: https://gerrit.openafs.org/14417
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 78e5e1b0e54b31bb08b7578e86a6a2a95770d94c)
    
    Change-Id: I9f9e2cd3a10cc8fa30a770cabd6ae9757f412ce5
    Reviewed-on: https://gerrit.openafs.org/14451
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit dc5e7825fb166ecdb32fc7b63b4a5316037de652
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Apr 20 14:51:08 2020 -0400

    vos: avoid 'half-locked' volume after interrupted 'vos rename'
    
    Reported symptoms:
    
    If a 'vos rename' is interrupted after it has locked the volume and
    replaced the VLDB entry, but before it has unlocked the volume, the
    volume will remain locked.  However, the locked volume will NOT be
    listed as locked in any vos commands that display locked status (see
    below for details).
    
    Background:
    
    Most vos write operations lock the VLDB volume entry before proceeding,
    then release the volume lock when finished.  This is accomplished via
    VL_SetLock and VL_ReleaseLock, respectively.
    
    VL_SetLock always sets these members in the VLDB volume entry:
    - flags is modified to set the required VLOP_* code bit as specified
    - LockAFSid is set to 0 (never implemented)
    - LockTimestamp is set to the current time
    
    VL_ReleaseLock always sets them as follows:
    - flags is cleared of any VLOP_* code bit
    - LockAFSid is set to 0 (never implemented)
    - LockTimestamp is set to 0
    
    VL_ReplaceEntry(N) may also optionally clear each of these members:
    - flags operation bits may be explicitly cleared via LOCKREL_OPCODE
    - LockAFSid may be explicitly cleared via LOCKREL_AFSID
    - LockTimestamp may be explicitly cleared via LOCKREL_TIMESTAMP
    
    When all 3 options are specified, VL_ReplaceEntry also does the
    functional equivalent of a VL_ReleaseLock.  Most vos operations use this
    method.  However, when no lock release options are specified on
    VL_ReplaceEntry(N), the VLDB entry is simply replaced with the supplied
    entry.  This includes whatever flags values are specified in the
    supplied entry; therefore, this amounts to an additional, implicit way
    to set or modify the flags.
    
    Root cause:
    
    'vos rename' (UV_RenameVolume) is the only vos operation that does all
    of the following things:
    - accepts a replacement volume entry that was obtained before VL_SetLock
      (and thus does NOT have any lock flags set)
    - issues VL_SetLock (which sets the lock flag in the VLDB)
    - issues VL_ReplaceEntry(N) with the original unlocked entry, and with
      no lock release options (thus with explicit intent to leave the lock
      flag unchanged, but inadvertently doing an implicit clear of the lock
      flag in the VLDB)
    - (performs some additional volserver work)
    - issues VL_ReleaseLock to release the volume lock
    
    Therefore, if 'vos rename' is cancelled or killed before reaching the
    final VL_ReleaseLock step, the VLDB entry is left with the lock flags
    cleared but the LockTimestamp still set.  As we will see below, this
    'half-locked' state produces confusing results from other vos commands.
    
    Detection of locked state:
    
    The 'vos lock' command (and all other vos commands that issue
    VL_SetLock) use the lock timestamp to determine if a volume is locked.
    
    However, several other vos commands ('vos listvldb <vol>', 'vos examine
    <vol>', 'vos listvldb -locked') use the VLDB entry's lock flags (not the
    lock timestamp) to determine if the volume is locked.  Therefore, if the
    lock flags have been cleared but the lock timestamp is still set, these
    commands fail to detect that the volume is still locked.  Yet an
    administrator's 'vos lock <volume>' will still fail with:
    
      Could not lock VLDB entry for volume <volume>
      VLDB: vldb entry is already locked
    
    This is the external manifestation of the 'half-locked' state.
    
    Workaround and fix:
    
    This scenario has a simple workaround: 'vos unlock <volume>'.  However,
    to avoid this confusing outcome in the first place, modify the 'vos
    rename' logic so that the lock flags are no longer inadvertently
    cleared.  Now, if the 'vos rename' is interrupted before the volume is
    unlocked, it will still appear locked in normal vos command output.
    
    Change-Id: Iefc6ef54ea4b0e95e3ae8e8a43d3ded0f15af0fa
    Reviewed-on: https://gerrit.openafs.org/14157
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-on: https://gerrit.openafs.org/14449
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a518b0c439b40886dcb2337919d49b3009a00b4d
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Nov 5 13:50:59 2020 -0700

    vos: Cleanup function definitions
    
    The functions defined within vos.c are not referenced outside of vos.c
    but are not declared as static.
    
    Convert the functions within vos.c to static declarations.
    
    Reviewed-on: https://gerrit.openafs.org/14009
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 56aa396d8359276d778d41aa509041c8c75b4e96)
    
    Change-Id: Idca045431959bb3e4b31d12ef754a883d4118a89
    Reviewed-on: https://gerrit.openafs.org/14448
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ab30c00f6ab663e0907830e76e76b44710712a07
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Nov 5 13:49:54 2020 -0700

    vos: Remove dead code
    
    Clean out dead code from vos.c
    
    GetVolumeType - not referenced anywhere
    CompareVLDBEntry - commented out since 1st git commit
    osi_audit - Comment indicates this might have been needed at one point.
                Builds without it.  Does not look like the vos executable
                is pulling in any of the audit code.
    RestoreVolume - remove stale comment about typo previous to openafs 1.0
    RemoveSite - remove commented out partition check
    
    Reviewed-on: https://gerrit.openafs.org/14008
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a3be2c74a95489f63837840af8ec42049ce021bf)
    
    Change-Id: I71a78d2a46b8d64cdde9db05a0079e9db954d191
    Reviewed-on: https://gerrit.openafs.org/14447
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 00095ea2eff4d8570af78044b88c2b2877ce4e2a
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Tue Nov 10 09:17:16 2020 -0700

    vos: Cleanup indentation whitespace
    
    Fix the indentation whitespace in vos.c, and remove double blank
    lines.  No functional change.
    
    Reviewed-on: https://gerrit.openafs.org/14007
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit c17c157641d83226fee5bc20f588f14bb132bb68)
    
    Change-Id: Iecde7505a3f59c4b6e59d4644b7a1e56127c272d
    Reviewed-on: https://gerrit.openafs.org/14446
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ebbeb69286ae408b59878074d06bc350001ad669
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri Dec 27 11:53:05 2019 -0500

    vsprocs: Remove dead code
    
    Remove the dead code in UV_VolumeMove() commented out with the macro
    ENABLE_BUGFIX_1165.
    
    Remove two commented out lines of code in UV_ConvertRO().
    
    Reviewed-on: https://gerrit.openafs.org/14004
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 6779e30d372b2cd5e7995da23ed5e2971124b79c)
    
    Change-Id: Ibeddebdf24ca50341bba3031c6f8548cab245b8a
    Reviewed-on: https://gerrit.openafs.org/14445
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 32742e3171e32970ee86449ef41d04df388a37f4
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Tue Oct 6 10:18:11 2020 -0400

    bozo: defer audit open until log dir is created and current
    
    On a new OpenAFS install where the log directory has not yet been
    created. 'bosserver -auditlog /usr/afs/logs/<auditlog>' (absolute path)
    fails with ENOENT because the log directory doesn't exist yet.
    
    Furthermore, 'bosserver -auditlog <auditlog>' (relative path) succeeds,
    but the audit file is created in the current working directory when
    bosserver was started, not in the expected log directory (Transarc
    /usr/afs/logs).
    
    Both problems have been present since bosserver audit log support was
    introduced by commit 16d67791dce45e5d4ee9b854c796492ffcde2113
    'auditlogs-for-everyone-20050702'.
    
    Reorder the bosserver initialization steps to ensure that the log
    directory has been created and is the current working directory, before
    creating and opening the audit log.
    
    Reviewed-on: https://gerrit.openafs.org/14381
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f372ec041a83288a5d096360f0ad8589e4db666a)
    
    Change-Id: I14a0a4a2a23c8e9b3b658d52511872ecaa4010af
    Reviewed-on: https://gerrit.openafs.org/14444
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 2473cfb5b98a0226c79e25649cb5cc52b9aea09b
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Sat Oct 17 20:51:51 2020 -0500

    bozo: Properly detect presence of -auditlog
    
    cmd_OptionAsString returns non-zero if the given option _isn't_ given
    (CMD_MISSING), so we need to call osi_audit_file only when
    cmd_OptionAsString returns 0. Since commit
    f6cdf71 (bozo: Use libcmd for command line options), this causes
    bosserver to complain on startup if no -auditlog was given:
    
        $ bosserver
        Warning: auditlog (null) not writable, ignored.
    
    To fix this, skip calling osi_audit_file if -auditlog was not given.
    
    While we're changing this anyway, change our processing of our
    audit-related options to more closely match what other daemons do,
    like ptserver or viced, so it's easier to see if we're doing the right
    thing. That is, just call cmd_OptionAsString() without a conditional,
    and just test if auditFileName is non-NULL later on, after options
    processing.
    
    Reviewed-on: https://gerrit.openafs.org/14402
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 87041d676c93dfe35a085b9b5aaa73e74c08bc90)
    
    Change-Id: Ic05e5453c28b4c408300ea35439a519adc282486
    Reviewed-on: https://gerrit.openafs.org/14443
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 633712a321f4cf51ffc6f97d2f9fabbb59b32a09
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Aug 21 12:53:30 2020 -0600

    bozo: Use libcmd for command line options
    
    Update bosserver to use libcmd for command line parsing.
    
    Reviewed-on: https://gerrit.openafs.org/13845
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit f6cdf7165b4e66772ee06314658b7c209928d611)
    
    Change-Id: I8fdf27d099f81c08a37db728846bd7596a8cf62e
    Reviewed-on: https://gerrit.openafs.org/14442
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit de0ec465625f18668325dfbe29337650ed98b560
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Fri Oct 28 18:12:19 2016 -0400

    afs: prevent double release of global lock afs_xvcb
    
    afs_GetServer calls ReleaseWriteLock(&afs_xvcb) twice within a few
    lines.  The second one is spurious.
    
    Commits b18653de7ae90491c2e75f4a98410581655d776c 'xserver lock order
    violation' and f2bf60ed4f1323cd6f74f2f01114f7e4f714db53 'xvcb lock order
    violation' were written by the same author at the same time and
    apparently were victims of a bad merge.
    
    Discovered during a lock audit project as a panic during afsd startup:
    
      assertion failed: (&afs_xvcb)->excl_locked == WRITE_LOCK, file:
      /home/mvitale/src/sna-openafs/src/afs/afs_server.c, line: 2089
    
    afs_GetServer is called frequently by many threads and so this bug could
    easily have released another thread's write lock on afs_xvcb.
    
    Remove the spurious second release.
    
    Reviewed-on: https://gerrit.openafs.org/14411
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit e8702e6a615a160cdbe464f76bd6f100667720d2)
    
    Change-Id: I3165a63e774296b97e09c374b068b012224776e1
    Reviewed-on: https://gerrit.openafs.org/14441
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b33c832facc53ff966071fd3ff0e5d6b33deb9cb
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Sep 18 19:45:10 2017 -0400

    stats: incorrect clock square algorithm
    
    Since the original IBM code import, OpenAFS has an algorithm for
    squaring clock values, implemented identically in three different
    places.  This algorithm does not account correctly for microsecs
    overflow into seconds, resulting in incorrect "sum-of-squares" values
    for queue and execution time in several OpenAFS performance utilities.
    
    Specifically, this code:
    
            t1.tv_usec += (2 * t2.tv_sec * t2.tv_usec) % 1000000                   \
                          + (t2.tv_usec / 1000)*(t2.tv_usec / 1000)                \
                          + 2 * (t2.tv_usec / 1000) * (t2.tv_usec % 1000) / 1000   \
                          + (((t2.tv_usec % 1000) > 707) ? 1 : 0);                 \
    
    Can allow for the tv_usec field to be increased by a theoretical max
    of around:
    
            t1.tv_usec += 999998                                                   \
                          + 999*999                                                \
                          + 2 * 999 * 999 / 1000                                   \
                          + 1;                                                     \
    
    Or:
    
            t1.tv_usec += 1999996;                                                 \
    
    If t1.tv_usec is already 999999, after this calculation its value
    could be as high as 2999995. So just checking once if t1.tv_usec is
    over 1000000 is not sufficient, since the resulting value (1999995) is
    still over 1000000.
    
    Correct all implementations by repeatedly checking if tv_usec is over
    1000000 after the above calculation:
    
    macro                   affected utility
    =====================   ============================
    afs_stats_SquareAddTo   xstat_cm_test
    fs_stats_SquareAddTo    xstat_fs_test
    clock_AddSq             rxstat_get_process and _peer
    
    Reviewed-on: https://gerrit.openafs.org/14376
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit e1e5df918fee00d4d9152c31c24cc1e7f23b71a6)
    
    Change-Id: I4055ed61311ed7d6ac435b8660d5b7c55f467699
    Reviewed-on: https://gerrit.openafs.org/14440
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 489308de9f62a3f881cd5f89d648c168a488c4d7
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Sep 28 16:35:38 2020 -0400

    rxstats: correctly report vlserver VL_* RPC stats
    
    Since the original IBM code import, rxstat_get_process and
    rxstat_get_peer have reported vlserver VL_* RPC stats as for the
    "volserver interface".
    
    Correct this to read "vlserver interface".
    
    Reviewed-on: https://gerrit.openafs.org/14375
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit e985d43d99d93172b5608a3c73fd3201d3b3a212)
    
    Change-Id: Ifbbe4df8ede22b287ab7c67d20e9ccd951367765
    Reviewed-on: https://gerrit.openafs.org/14439
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ffc5b608ab3e99d654561b1a3f4b3a873a6af1c0
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Sep 28 15:40:34 2020 -0400

    rxstats: correctly distinguish client and server stats
    
    Commit d3eaa39da3693bba708fa2fa951568009e929550 'rx: Make the rx_call
    structure private' inadvertently caused all rxstats (aka rpcstats) to be
    recorded as client stats by hardcoding the value for isServer to 1.
    
    Therefore, when peer or process rxstats are enabled for a OpenAFS
    component, the rxstat_get_process and rxstat_get_peer utilities will
    erroneously report both client and server stats as "accessed as a client".
    
    This is particularly problematic for ubik VOTE_* and DISK_* RPC stats,
    for which a given ubik server may be both client and server over time.
    In this case, both client and server stats are conflated into the same
    "accessed as a client" counters.
    
    Instead, properly pass the value of isServer from
    rx_RecordCallStatistics through to rxi_IncrementTimeAndCount.
    
    Note to maintainers:
    This bug is only in master and all 1.8.x releases; no 1.6.x releases are
    affected.
    
    Note:
    Confusingly, isServer=1 indicates client stats and isServer=0 indicates
    server stats.  However, this is a quirk of the original implementation
    and wire format of the RXSTATS_* RPCs and cannot be changed.  isServer
    is actually shorthand for "remote is server"; thus all RPC client stubs
    record their rxstats with isServer == 1, and all RPC server stubs record
    their rxstats with isServer == 0.
    
    Reviewed-on: https://gerrit.openafs.org/14374
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 18c345a9f8ee9b2ff73f23dae68757b19d3283f5)
    
    Change-Id: I6d41d015803967363f3702f5dda7083ccbf7508a
    Reviewed-on: https://gerrit.openafs.org/14438
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5d863b4f6e817b1cc2615265c7747e17a2037ae6
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Oct 26 12:19:19 2020 -0500

    afs: Log pid with disk cache read errors
    
    Log the current pid (and procname) when we complain about an error
    when reading from CacheItems in afs_UFSGetDSlot. These errors can
    result in confusing situations, so it can be helpful to know at least
    what process saw the error.
    
    Our logic for logging this information is getting a bit large, so also
    move this to a new function, LogCacheError.
    
    Reviewed-on: https://gerrit.openafs.org/14416
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 1caeeea43c038011306dd1c391680c24fc318e3d)
    
    Change-Id: Ia159eeea47191f71fc5892cbc54af79b55bf4828
    Reviewed-on: https://gerrit.openafs.org/14437
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c7c8f75ebf812f1943aa9efd76dde26be99c96b1
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Nov 12 15:06:09 2018 -0600

    vlserver: Return VL_DBBAD on unhash failure
    
    If we try to delete a vlentry, and the vlentry cannot be found on one
    of its hash chains, we cannot unhash the vlentry properly and the
    operation fails with VL_NOENT. This results in the following error
    messages to the user:
    
            $ vos delentry 123456
            Could not delete entry for volume 123456
            You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
            VLDB: no such entry
            Deleted 0 VLDB entries
    
    This is confusing, because VL_NOENT can also occur if the user
    specifies a volume that does actually not exist. This situation is
    indicative of database corruption, usually because of a ubik
    transaction that was only half-applied, or because of other ubik bugs
    in the past.
    
    The situation can only really be fixed by repairing the database, so
    return VL_DBBAD in this case instead, to more clearly indicate that
    something is wrong with the database, and not a problem with the
    arguments the caller provided.
    
    Reviewed-on: https://gerrit.openafs.org/13384
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit fd6add0aca03a5a17f7109c785b6027a76f13cdf)
    
    Change-Id: Ib1cf72b7f0d6c65e37c13f00d6f6049a3049b644
    Reviewed-on: https://gerrit.openafs.org/14436
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 751aa775da1c76a495cf1b0754185cb4cdc23fbe
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Nov 12 14:41:44 2018 -0600

    vlserver: Add VL_DBBAD error code
    
    The VL_ error table currently doesn't have an error code to indicate
    that an operation cannot succeed because the database is corrupted.
    There are a few error codes for specific cases of errors that are
    probably the result of corruption (like VL_IDALREADYHASHED, or
    VL_EMPTY), but these are only for specific cases and indicate rather
    low-level internal problems.
    
    There are some instances where the real problem preventing an
    operation from succeeding is that the database is just corrupt or
    inconsistent in some way, and the administrator must repair the
    database before it can succeed. And we currently don't have any way of
    indicating that situation via an error code.
    
    So, introduce the VL_DBBAD code, to indicate this situation. Error
    codes already exist in other tables for similar situations, such as
    PRDBBAD, and KADATABASEINCONSISTENT.
    
    This commit does not use the new error code anywhere; we just
    introduce it into the VL_ error table, so comerr-using applications
    will be able to interpret it.
    
    Note that the VL_DBBAD error code has been recognized by the AFS
    Assigned Numbers Registry as recorded in the ticket history of
    <https://rt.central.org/rt/Ticket/Display.html?id=134817>
    
    Reviewed-on: https://gerrit.openafs.org/13383
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 878d27c845157bb64c32bbd6c3cacce17c681d70)
    
    Change-Id: I93b4916890ec9e4f6f5453ecf28c8a8ce04af7ea
    Reviewed-on: https://gerrit.openafs.org/14435
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 27a2cdadd221d4a870d5ce9b936bb103c605cafb
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Nov 12 15:01:18 2018 -0600

    vlserver: Warn when we cannot unhash deleted entry
    
    If we are trying to delete an entry from the vldb, we fail with
    VL_NOENT if we cannot find the given entry on one of its hash chains.
    This is indicative of corruption in the vldb (since we have an entry
    not on a hash chain), but we don't really indicate this clearly. There
    are no log messages, and the user running 'vos' only sees an error
    like this:
    
        $ vos delentry 123456
        Could not delete entry for volume 123456
        You must specify a RW volume name or ID (the entire VLDB entry will be deleted)
        VLDB: no such entry
        Deleted 0 VLDB entries
    
    Which is the exact same error message if the user tries to delete a
    volume that does not actually exist.
    
    We currently do not have an error code that clearly says that the
    database appears corrupted and needs to be fixed, but we can at least
    log an error in VLLog for this case, to give the administrator a
    chance at fixing the situation. So, log a message in this situation.
    
    Reviewed-on: https://gerrit.openafs.org/13382
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 3e3fce24da31a31ca9a3f4ad356c4e4eaf0ad897)
    
    Change-Id: Ia76c5d7a19c3d21a89fc502e14922672afd8a84f
    Reviewed-on: https://gerrit.openafs.org/14434
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 757b90ef33f7d5f00c4b1990c2300f6502a3b74a
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Thu Sep 3 23:57:34 2020 +0000

    volser: take RO volume offline during convertROtoRW
    
    The vos convertROtoRW command converts a RO volume into a RW volume.
    Unfortunately, the RO volume is not checked out from the fileserver
    during this process. As a result, accesses to the volume being converted
    can leave volume objects in an inconsistent state.
    
    Moreover, consider the following scenario:
    
    1. Create a volume on host_b and add replicas on host_a and host_b.
    
    $ vos create host_b a vol_1
    $ vos addsite host_b a vol_1
    $ vos addiste host_a a vol_1
    
    2. Mount the volume:
    
    $ fs mkmount /afs/.mycell/vol_1 vol_1
    $ vos release vol_1
    $ vos release root.cell
    
    3. Shutdown dafs on host_b:
    
    $ bos shutdown host_b dafs
    
    4. Remove RO reference to host_b from the vldb:
    
    $ vos remsite host_b a vol_1
    
    5. Attach the RO copy by touching it:
    
    $ fs flushall
    $ ls /afs/mycell/vol_1
    
    6. Convert RO copy to RW:
    
    $ vos convertROtoRW host_a a vol_1
    
    Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving
    the volume object for the RO copy set as VOL_STATE_ATTACHED (on success,
    this volume should be set as VOL_STATE_DELETED).
    
    7. Add replica on host_a:
    
    $ vos addsite host_a a vol_1
    
    8. Wait until the "inUse" flag of the RO entry is cleared (or force this
    to happen by attaching multiple volumes).
    
    9. Release the volume:
    
    $ vos release vol_1
    
    Failed to start transaction on volume 536870922
    Volume not attached, does not exist, or not on line
    Error in vos release command.
    Volume not attached, does not exist, or not on line
    
    Notice that this happens because we cannot mark an attached volume as
    destroyed (FSYNC_com_VolDone).
    
    To avoid the problem mentioned above and to prevent accesses to the
    volume being converted, take the RO volume offline before converting it
    to RW.
    
    Reviewed-on: https://gerrit.openafs.org/14340
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 45a69b61133ae8ca8e49a002ddc1895386796d51)
    
    Change-Id: I94e08d09d5044f3c0cac7c700f26ec6e7b111d6f
    Reviewed-on: https://gerrit.openafs.org/14433
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    Tested-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 199d485ee862c21c43008e1fd4b226517d20068c
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Thu Sep 3 20:11:34 2020 +0000

    volser: Close dirp on error in ConvertROtoRW
    
    Currently, if SAFSVolConvertROtoRWvolume cannot create a new transaction
    for the volume to be converted, it returns without closing the directory
    stream opened by it. To prevent this leak, go through a new 'goto done'
    destructor if NewTrans fails.
    
    Reviewed-on: https://gerrit.openafs.org/14342
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f18b58f8227df2ab420d69eb5937a99f747c7692)
    
    Change-Id: I81b5f7a330548eaecba1acfdc7231d2a953a365b
    Reviewed-on: https://gerrit.openafs.org/14432
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit cc6b15564eaf94bcb41f930f396f1c1e4804fa18
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Thu Apr 16 16:29:09 2020 -0400

    vlserver: fix missing read-only entries from ListAttributesN2
    
    The ListAttributesN2() RPC can fail to list read-only entries under
    certain circumstances. This RPC is used by the `vos listvldb` command to
    retrieve vldb entries (unless the -name option is given). The `vos
    listvldb` command fails to list volume entries when run with the
    '-server' option for volumes that have read-only replicas, but have not
    been released.
    
    Consider the following example volume:
    
        $ vos create fs1.example.com a test
        $ vos addsite fs1.example.com a test
        $ vos addsite fs2.example.com a test
        $ vos listvldb
        ...
        test
            RWrite: 536870921
            number of sites -> 3
               server fs1.example.com partition /vicepa RW Site
               server fs1.example.com partition /vicepa RO Site  -- Not released
               server fs2.example.com partition /vicepa RO Site  -- Not released
    
    `vos listvldb` fails to find the volume when the search is limited to
    server 'fs2':
    
        $ vos listvldb -server fs2.example.com
        VLDB entries for server fs2.example.com
        Total entries: 0
    
    Instead of the expected results:
    
        $ vos listvldb -server fs2.example.com
        test
            RWrite: 536870921
            number of sites -> 3
               server fs1.example.com partition /vicepa RW Site
               server fs1.example.com partition /vicepa RO Site  -- Not released
               server fs2.example.com partition /vicepa RO Site  -- Not released
    
    This situation makes it difficult to remove old server addresses from
    the vldb.  In this situation, 'vos remaddrs' and 'vos changeaddr
    -remove' commands will complain the server addresses are still in use by
    volume entries, however running 'vos listvldb -server' will not show
    which volumes entries are in use.
    
    The entries are not listed for unreleased volumes because the
    ListAttributesN2() RPC is currently checking the volume VLF_ROEXISTS
    flag, instead of the server site flags (serverFlags) to determine when
    the entry is a read-only site. The volume VLF_ROEXISTS flag is set when
    a volume is released.
    
    To fix this, make ListAttributesN2 check for the VLSF_ROVOL site flag,
    instead of the VLF_ROEXISTS entry flag.
    
    Reviewed-on: https://gerrit.openafs.org/14154
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 904f5bd398db248c11b30ef7e360ce5141dcd1f3)
    
    Change-Id: Iea4bbbc9fb0c42ac5e109ee94688436fdcc42a67
    Reviewed-on: https://gerrit.openafs.org/14427
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit b7ddd1262117332871e7cd537aa6065b78a41bb2
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jun 18 21:16:09 2020 -0500

    LINUX: Close cacheFp if no ->readpage in fastpath
    
    In afs_linux_readpage_fastpath, if we discover that our disk cache fs
    has no ->readpage function, we'll 'goto out', but we never close our
    cacheFp. To make sure we close it, add a filp_close() call to the
    'goto out' cleanup code.
    
    Reviewed-on: https://gerrit.openafs.org/14252
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit f9d20c631d7280ce00125a1208331931a6e3f31c)
    
    Change-Id: If409c50e5515cd80f77171a90fd96e2d3fb575a8
    Reviewed-on: https://gerrit.openafs.org/14421
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 610e50b70c666f72a6d8b02e1759ac1dece10dd3
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri Aug 28 11:24:10 2020 -0400

    bozo: Log each dir and file with bad access rights
    
    The bosserver directory and file access check stops after finding one
    directory or file with incorrect permissions or owner. A log message is
    written for this first one found, but more than one directory or file
    may have incorrect access rights.
    
    Instead check all of them so the bosserver logs a warning message for
    each incorrect director or file permission found.  This should make it
    easier to fix all of the file permission problems at once.
    
    Reviewed-on: https://gerrit.openafs.org/14330
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 47d809d4434f6724d0b6fbe2dcb54749486eeddb)
    
    Change-Id: Ieffac018628e1b3a1ad930b72312f596ee452b43
    Reviewed-on: https://gerrit.openafs.org/14420
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 712ef18ac1902fabc540883827b1925769e0a050
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri Aug 28 11:23:00 2020 -0400

    bozo: Add KeyFileExt and rxkad.keytab to access rights check
    
    When the KeyFileExt and rxkad.keytab were added to OpenAFS, they were
    not added to the bosserver's access rights check. Add these files to the
    bosserver access checks, with the same access rights needed for the
    original KeyFile.
    
    Also, add the full path for KeyFileExt to the dirpath package (not just
    the filename), which was not done when the KeyFileExt was introduced.
    This is needed to perform the access checks.
    
    Reviewed-on: https://gerrit.openafs.org/14329
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a6b14ea90259fbc4ead62f5f4288e435801db81e)
    
    Change-Id: I94d9027f9455ee8a8f307864ffa49debaf579e71
    Reviewed-on: https://gerrit.openafs.org/14419
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 62beb979b4e43c361db54fbf3084f876fd2c11da
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Jul 16 16:53:34 2018 -0500

    afs: Skip bulkstat if stat cache looks full
    
    Currently, afs_lookup() will try to prefetch dir entries for normal
    dirs via bulkstat whenever multiple pids are reading that dir.
    However, if we already have a lot of vcaches, ShakeLooseVCaches may be
    struggling to limit the vcaches we already have. Entering
    afs_DoBulkStat can make this worse, since we grab afs_xvcache
    repeatedly, we may kick out other vcaches, and we'll possibly create
    30 new vcaches that may not even be used before they're evicted.
    
    To try to avoid this, skip running afs_DoBulkStat if it looks like the
    stat cache is really full.
    
    Reviewed-on: https://gerrit.openafs.org/13256
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 9ff45e73cf3d91d12f09e108e1267e37ae842c87)
    
    Change-Id: I1b84ab3bb918252e8db5e4379730a517181bc9d8
    Reviewed-on: https://gerrit.openafs.org/14400
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 28794011085d35b293d5e829adadb372b2a2b3fd
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Jul 16 16:44:14 2018 -0500

    afs: Log warning when we detect too many vcaches
    
    Currently, afs_ShakeLooseVCaches has a kind of warning that is logged
    when we fail to free up any vcaches. This information can be useful to
    know, since it may be a sign that users are trying to access way more
    files than our configured vcache limit, hindering performance as we
    constantly try to evict and re-create vcaches for files.
    
    However, the current warning is not clear at all to non-expert users,
    and it can only occur for non-dynamic vcaches (which is uncommon these
    days).
    
    To improve this, try to make a general determination if it looks like
    the stat cache is "stressed", and log a message if so after
    afs_ShakeLooseVCaches runs (for all platforms, regardless of dynamic
    vcaches). Also try to make the message a little more user-friendly,
    and only log it (at most) once per 4 hours.
    
    Determining whether the stat cache looks stressed or not is difficult
    and arguably subjective (especially for dynamic vcaches). This commit
    draws a few arbitrary lines in the sand to make the decision, so at
    least something will be logged in the cases where users are constantly
    accessing way more files than our configured vcache limit.
    
    Reviewed-on: https://gerrit.openafs.org/13255
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 0532f917f29bdb44f4933f9c8a6c05c7fecc6bbb)
    
    Change-Id: Ic7260f276e00f3e34541207955df841d4ed27844
    Reviewed-on: https://gerrit.openafs.org/14399
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 47ab46e1e9fe56b5bf8147eab0b652e74078cbe7
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Jul 16 16:08:13 2018 -0500

    afs: Split out bulkstat conditions into a function
    
    Our current if() statement for determining whether we should run
    afs_DoBulkStat to prefetch dir entries is a bit large, and grows over
    time. Split this logic out into a separate function to make it easier
    to maintain, and add some comments to help explain each condition.
    
    This commit should have no visible effects; it's just code
    reorganization.
    
    Reviewed-on: https://gerrit.openafs.org/13254
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 19cd454f11997d286bc415e9bc9318a31f73e2c6)
    
    Change-Id: Ida322c518d11787fd794df7534135fbc2dec2935
    Reviewed-on: https://gerrit.openafs.org/14398
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 738eb3e4976947657f877ec107d517d63a66a907
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Sun Jul 8 15:00:02 2018 -0500

    afs: Bound afs_DoBulkStat dir scan
    
    Currently, afs_DoBulkStat will scan the entire directory blob, looking
    for entries to stat. If all or almost all entries are already stat'd,
    we'll scan through the entire directory, doing nontrivial work on
    each entry (we grab afs_xvcache, at least). All of this work is pretty
    pointless, since the entries are already cached and so we won't do
    anything. If many processes are trying to acquire afs_xvcache, this
    can contribute to performance issues.
    
    To avoid this, provide a constant bound on the number of entries we'll
    search through: nentries * 4. The current arbitrary limits cap
    nentries at 30, so this means we're capping the afs_DoBulkStat search
    to 120 entries.
    
    Reviewed-on: https://gerrit.openafs.org/13253
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit ba8b92401b8cb2f5a5306313c2702cb36cba083c)
    
    Change-Id: Icf82f88328621cb5a9e0ad52f873b8a7d74b1f3a
    Reviewed-on: https://gerrit.openafs.org/14397
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fbba8e4cbf00f32181b5075e8d7a876cccd2a046
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jul 13 17:40:36 2017 -0500

    afs: Avoid needless W-locks for afs_FindVCache
    
    The callers of afs_FindVCache must hold at least a read lock on
    afs_xvcache; some hold a shared or write lock (and set IS_SLOCK or
    IS_WLOCK in the given flags). Two callers (afs_EvalFakeStat_int and
    afs_DoBulkStat) currently hold a write lock, but neither of them need
    to.
    
    In the optimal case, where afs_FindVCache finds the given vcache, this
    means that we unnecessarily hold a write lock on afs_xvcache. This can
    impact performance, since afs_xvcache can be a very frequently
    accessed lock (a simple operation like afs_PutVCache briefly holds a
    read lock, for example).
    
    To avoid this, have afs_DoBulkStat hold a shared lock on afs_xvcache,
    upgrading to a write lock when needed. afs_EvalFakeStat_int doesn't
    ever need a write lock at all, so just convert it to a read lock.
    
    Reviewed-on: https://gerrit.openafs.org/12656
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 6c808e05adb0609e02cd61e3c6c4c09eb93c1630)
    
    Change-Id: Id517d1098b4c3a02db646b2a74535f77cb684ec3
    Reviewed-on: https://gerrit.openafs.org/14396
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5c476b91fd2259e9c34070be8ba201dd471ad974
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Jul 13 17:40:21 2017 -0500

    afs: Change VerifyVCache2 calls to VerifyVCache
    
    afs_VerifyVCache is a macro that (on most platforms) effectively
    expands to:
    
        if ((avc->f.states & CStatd)) {
            return 0;
        } else {
            return afs_VerifyVCache2(...);
        }
    
    Some callers call afs_VerifyVCache2 directly, since they already check
    for CStatd for other reasons. A few callers currently call
    afs_VerifyVCache2, but without guaranteeing that CStatd is not set.
    Specifically, in afs_getattr and afs_linux_VerifyVCache, CStatd could
    be set while afs_CreateReq drops GLOCK. And in afs_linux_readdir,
    CStatd could be cleared at multiple different points before the
    VerifyVCache call.
    
    This can result in afs_VerifyVCache2 acquiring a write-lock on the
    vcache, even when CStatd is already set, which is an unnecessary
    performance hit.
    
    To avoid this, change these call sites to use afs_VerifyVCache instead
    of calling afs_VerifyVCache2 directly, which skips the write lock when
    CStatd is already set.
    
    Reviewed-on: https://gerrit.openafs.org/12655
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a05d5b7503e466e18f5157006c1de2a2f7d019f7)
    
    Change-Id: I05bdcb7f10930ed465c24a8d7e51077a027b1a4b
    Reviewed-on: https://gerrit.openafs.org/14395
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 150ee65f286409e37fcf94807dbeaf4b79ab0769
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Sun Apr 26 17:26:02 2020 -0500

    rx: Use _IsLast to check for last call in queue
    
    Ever since commits 170dbb3c (rx: Use opr queues) and d9fc4890 (rx: Fix
    test for end of call queue for LWP), rx_GetCall checks if the current
    call is the last one on rx_incomingCallQueue by doing this:
    
        opr_queue_IsEnd(&rx_incomingCallQueue, cursor)
    
    But opr_queue_IsEnd checks if the given pointer is the _end_ of the
    last; that is, if it's the end-of-list sentinel, not an item on the
    actual list. Testing for the last item in a list is what
    opr_queue_IsLast is for. This is the same convention that the old Rx
    queues used, but 170dbb3c just accidentally replaced queue_IsLast with
    opr_queue_IsEnd (instead of opr_queue_IsLast), and d9fc4890 copied the
    mistake.
    
    So because this is inside an opr_queue_Scan loop, opr_queue_IsEnd will
    never be true, so we'll never enter this block of code (unless we are
    the "fcfs" thread). This means that an incoming Rx call can get stuck
    in the incoming call queue, if all of the following are true:
    
     - The incoming call consists of more than 1 packet of incoming data.
    
     - The incoming call "waits" when it comes in (that is, there are no
       free threads or the service is over quota).
    
     - The "fcfs" thread doesn't scan the incoming call queue (because it
       is idle when the call comes in, but the relevant service is over
       quota).
    
    To fix this, just use opr_queue_IsLast here instead of
    opr_queue_IsEnd.
    
    Reviewed-on: https://gerrit.openafs.org/14158
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit befc72749884c6752c7789479343ba48c7d5cea1)
    
    Change-Id: If724245414798ae7a86dfa048cf99863317aef8e
    Reviewed-on: https://gerrit.openafs.org/14394
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 12aed9ef2988a69187910bada5ba7325cb6144ab
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 21 18:48:51 2019 -0500

    rx: Avoid osi_NetSend during rx shutdown
    
    Commit 8d939c08 (rx: avoid nat ping during shutdown) added a call
    to shutdown_rx() inside the DARWIN shutdown sequence, before the rx
    socket was closed. From the commit message, it sounds like this was
    done to avoid NAT pings from calling osi_NetSend during the shutdown
    sequence after the rx socket was closed; calling shutdown_rx() before
    closing the socket would cause any connections we had to be destroyed
    first, avoiding that.
    
    The problem with this is that this means shutdown_rx() is called when
    osi_StopNetIfPoller is called, which is much earlier than some other
    portions of the shutdown sequence; some of which may hold references
    to e.g. rx connections. If we try to, for instance, destroy an rx
    connection after shutdown_rx() is called, we could panic.
    
    An earlier version of that commit (gerrit PS1) just tried to insert a
    check before the relevant osi_NetSend call, making us just skip the
    osi_NetSend if the shutdown sequence had been started. So to avoid the
    above issue, try to implement that approach instead. And instead of
    doing it just for NAT pings, we can do it for almost all osi_NetSend
    calls (besides those involved in the shutdown sequence itself), by
    checking this in rxi_NetSend. Also return an error (ESHUTDOWN) if we
    skip the osi_NetSend call, so we're not completely silent about doing
    so.
    
    This means we also remove the call to shutdown_rx() inside DARWIN's
    osi_StopNetIfPoller(). This allows us to interact with Rx objects
    during more of the shutdown process in cross-platform code.
    
    Reviewed-on: https://gerrit.openafs.org/13718
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 9866511bb0a5323853e97e3ee92524198813776e)
    
    Change-Id: Ie62c1a68d8a8889f7a8aa3eff3973c219b45a95c
    Reviewed-on: https://gerrit.openafs.org/14393
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7f59989cf84df1e2077f4fcf5649c9624e79a5d2
Author: Andrew Deason <adeason@dson.org>
Date:   Sun Jul 21 18:31:53 2019 -0500

    rx: Introduce rxi_NetSend
    
    Introduce a small wrapper around osi_NetSend, called rxi_NetSend. This
    small wrapper allows future commits to change the code around our
    osi_NetSend calls, without needing to change every single call site,
    or every implementation of osi_NetSend.
    
    Change most call sites to use rxi_NetSend, instead of osi_NetSend. Do
    not change a few callers in the platform-specific kernel shutdown
    sequence, since those call osi_NetSend for platform-specific reasons.
    
    This commit on its own does not change any behavior with osi_NetSend;
    it is just code reorganization.
    
    Reviewed-on: https://gerrit.openafs.org/13717
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 2a33a80f7026df6b5e47e42319c55d8b7155675a)
    
    Change-Id: I6af8541953a582d044fb668eb4a91720536bc8e1
    Reviewed-on: https://gerrit.openafs.org/14392
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 38f613f5e15552938cb425c68b22c166e35284be
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Oct 13 20:18:59 2020 -0500

    ubik: Remove unused sampleName
    
    The RPC-L type sampleName and related constant UMAXNAMELEN are not
    referenced by anything, and have been unused since OpenAFS 1.0. Remove
    the unused definitions.
    
    Reviewed-on: https://gerrit.openafs.org/14386
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 83ce8d41c68a5ebcc84132d77af9024c6d285e05)
    
    Change-Id: I1d6c583d9c630fc9704578ba3329132e16b3a803
    Reviewed-on: https://gerrit.openafs.org/14401
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit f7374a883505aa34a3db34ddd1163367c544bb0c
Author: Andrew Deason <adeason@dson.org>
Date:   Sat May 2 23:54:55 2020 -0500

    afs: Drop GLOCK for RXAFS_GetCapabilities
    
    We are hitting the net here; we certainly should not be holding
    AFS_GLOCK while waiting for the server's response.
    
    Found via FreeBSD WITNESS.
    
    Reviewed-on: https://gerrit.openafs.org/14181
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 44b7b93b593371bfdddd0be0ae603f4f8720f78b)
    
    Change-Id: I186e08c89136cc3109fd2519bb0d2abbb52f9ba0
    Reviewed-on: https://gerrit.openafs.org/14391
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 02fb067d3fded0eee5c9326c56e66b512a75d71c
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Mon Mar 23 09:46:05 2020 -0400

    build: remove unused LINUX_PKGREL from configure.ac
    
    This change removes the unused LINUX_PKGREL definition from the
    configure.ac file.
    
    Commit 6a27e228bac196abada96f34ca9cd57f32e31f5c converted the setting of
    the RPM package version and release values in the openafs.spec file from
    autoconf to the makesrpm.pl script. That commit left LINUX_PKGREL in
    configure.ac because it was still referenced by the Debian packaging,
    which was still in-tree at that time.
    
    Commit ada9dba0756450993a8e57c05ddbcae7d1891582 removed the last trace
    of the Debian packaging, but missed the removal of the LINUX_PKGREL.
    
    Reviewed-on: https://gerrit.openafs.org/14117
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 8ae4531c5720baff9e11e4b05706eab6c82de5f9)
    
    Conflicts:
    	configure.ac
    
    Change-Id: I69925f89c52aef32aea5bc308140936517b1aeb0
    Reviewed-on: https://gerrit.openafs.org/14363
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 2f2cbff766650e7c25eb332d5385f4a3fca8676d
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Apr 20 13:03:15 2020 -0500

    ubik: Avoid unlinking garbage during recovery
    
    In urecovery_Interact, if any of our operations fail around
    calling DISK_GetFile, we will jump to FetchEndCall and eventually
    unlink 'pbuffer'. But if we failed before opening our .DB0.TMP file,
    the contents of 'pbuffer' will not be initialized yet.
    
    During most iterations of the recovery loop, the contents of 'pbuffer'
    will be filled in from previous loops, and it should always stay the
    same, so it's not a big problem. But if this is the first iteration of
    the loop, the contents of 'pbuffer' may be stack garbage.
    
    Solve this in two ways. To make sure we don't use garbage contents in
    'pbuffer', memset the whole thing to zeroes at the beginning of
    urecovery_Interact(). And then to make sure we're not reusing
    'pbuffer' contents from previous iterations of the loop, also clear
    the first character to NUL each time we arrive at this area of the
    recovery code. And avoid unlinking anything if pbuffer starts with a
    NUL.
    
    Commit 44e80643 (ubik: Avoid unlinking garbage) fixes the same issue,
    but only fixed it in the SDISK_SendFile codepath in remote.c.
    
    Reviewed-on: https://gerrit.openafs.org/14153
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 98b5ffb52117aefac5afb47b30ce9b87eb2fdebf)
    
    Change-Id: I5cadb88e466ddd326ef1e4138d5b1bf89fdb27dc
    Reviewed-on: https://gerrit.openafs.org/14365
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 8993e35578e4ae51dd5e8941f77c18bb975e51af
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri Sep 18 14:03:37 2020 -0600

    WINNT: Make opr_threadname_set a no-op
    
    We don't supply an implementation for opr_threadname_set for WINNT;
    don't pretend that we do.
    
    Reviewed-on: https://gerrit.openafs.org/13817
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f895a9b51671ffdc920fd9b4284337c5b737a0ef)
    
    Change-Id: Ie8df82550f5420e2b024dea29aae0e39e3ee506f
    Reviewed-on: https://gerrit.openafs.org/14369
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 045a97dfbc8dd6a2794b74e16f47984dc5f8eccf
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri Sep 18 12:11:36 2020 -0600

    Move afs_pthread_setname_self to opr
    
    Move the functionality in afs_pthread_setname_self from libutil to
    opr, in a new function opr_threadname_set. This allows us to more
    easily use the routine in more subsystems, since most code already
    uses opr.
    
    Reviewed-on: https://gerrit.openafs.org/13655
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 9d28f7390332c92b3d9e863c6fe70c26db28b5ad)
    
    Change-Id: Ic6bbb615bc3494a7a114a0f4cae711b65ebec111
    Reviewed-on: https://gerrit.openafs.org/14368
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 41f4bb48741065da6a69ffcb05e451e5c7dac757
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Mon Aug 31 19:56:56 2020 +0000

    Revert "vos: take RO volume offline during convertROtoRW"
    
    This reverts commit 32d35db64061e4102281c235cf693341f9de9271. While that
    commit did fix the mentioned problem, depending on "vos" to set the
    volume to be converted as "out of service" is not ideal. Instead, this
    volume should be set as offline by the SAFSVolConvertROtoRWvolume RPC,
    executed on the volume server.
    
    The proper fix for this problem will be introduced by another commit.
    
    Reviewed-on: https://gerrit.openafs.org/14339
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 85893ac3df0c2cb48776cf1203ec200507b6ce7d)
    
    Change-Id: Ie125d2dae1301ca5a4f8323099e6e42bc57b6d28
    Reviewed-on: https://gerrit.openafs.org/14361
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 29cdc0af10cb2a0f4cb4d1b05e72d6f066a1a7a5
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Apr 15 05:33:00 2020 -0500

    LINUX: Always crref after _settok_setParentPag
    
    Commit b61eac78 (Linux: setpag() may replace credentials) changed
    PSetTokens2 to call crref() after _settok_setParentPag(), since
    changing the parent PAG may change our credentials structure. But that
    commit did not update the old pioctl PSetTokens, so -setpag
    functionality remained broken on Linux for utilities that called the
    old pioctl ('klog' is one such utility).
    
    To fix this, we could copy the same code from PSetTokens2 into
    PSetTokens. But instead just move this code into _settok_setParentPag
    itself, to avoid code duplication. This commit also refactors
    _settok_setParentPag a little to make the platform-specific ifdefs a
    little easier to read through.
    
    Reviewed-on: https://gerrit.openafs.org/14147
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 8002a46125e8224ba697c194edba5ad09e4cfc44)
    
    Change-Id: I6a9d10428fe470cb38e3ca669f273dde0fa9c875
    Reviewed-on: https://gerrit.openafs.org/14328
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 9553128008c7656d78759aa685a574906d352f3c
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Apr 15 05:33:00 2020 -0500

    LINUX: Copy session keys to parent in SetToken
    
    Commit 48589b5d (Linux: Restore aklog -setpag functionality for kernel
    2.6.32+) added code to SetToken() to copy our session keyring to the
    parent process, in order to implement -setpag functionality. But this
    was removed from SetToken() in commit 1a6d4c16 (Linux: fix aklog
    -setpag to work with ktc_SetTokenEx), when the same code was moved to
    ktc_SetTokenEx().
    
    Add this code back to SetTokens(), so -setpag functionality can work
    again with utilities that use older functions like ktc_SetToken, like
    'klog'.
    
    Reviewed-on: https://gerrit.openafs.org/14146
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 826bb826274e48c867b41cb948d031a423373901)
    
    Change-Id: I1ae90d92efa27bce2ff59ff9b9dcca370eaf4730
    Reviewed-on: https://gerrit.openafs.org/14327
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 01dfdf2608c5643714da61950637c1e7d1994023
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Fri Aug 21 01:54:00 2020 +0530

    afs: Avoid NatPing event on all connection
    
    Inside release_conns_user_server, connection vector is traversed and after
    destroying a connection new eligible connection is found on which NatPing
    event will be set. Ideally there should be only one connection on which
    NatPing should be set but in current code while traversing all connection
    of server a NatPing event is set on all connections to that server. In
    cases where we have large number of connection to a server this can lead
    to huge number of “RX_PACKET_TYPE_VERSION” packets sent to a server.
    Since this happen during Garbage collection of user structs, to simulate
    this issue below steps were tried
    
      - had one script which “cd” to a volume mount and then script sleeps for
        large time.
      - Ran one infinite while loop where above script was called using PAG
        based tokens (As new connection will be created for each PAG)
      - Instrumented the code, so that we hit above code segment where NatPing
        event is set. Mainly reduced NOTOKTIMEOUT to 60 sec.
    
    To fix this issue set NatPing on one connection and once it is set break
    from “for” loop traversing the server connection.
    
    Reviewed-on: https://gerrit.openafs.org/14312
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit b968875a342ba8f11378e76560b46701f21391e8)
    
    Change-Id: I8c70108ab3eb73ed1d9e598381bc29b87ca42aa0
    Reviewed-on: https://gerrit.openafs.org/14364
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit e4103743d91bcdba1c57c850eb07b0b03abe72d6
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Mon Jun 22 22:54:52 2020 -0500

    volser: Don't NUL-pad failed pread()s in dumps
    
    Currently, the volserver SAFSVolDump RPC and the 'voldump' utility
    handle short reads from pread() for vnode payloads by padding the
    missing data with NUL bytes. That is, if we request 4k of data for our
    pread() call, and we only get back 1k of data, we'll write 1k of data
    to the volume dump stream followed by 3k of NUL bytes, and log
    messages like this:
    
        1 Volser: DumpFile: Error reading inode 1234 for vnode 5678
        1 Volser: DumpFile: Null padding file: 3072 bytes at offset 40960
    
    This can happen if we hit EOF on the underlying file sooner than
    expected, or if the OS just responds with fewer bytes than requested
    for any reason.
    
    The same code path tries to do the same NUL-padding if pread() returns
    an error (for example, EIO), padding the entire e.g. 4k block with
    NULs. However, in this case, the "padding" code often doesn't work as
    intended, because we compare 'n' (set to -1) with 'howMany' (set to 4k
    in this example), like so:
    
        if (n < howMany)
    
    Here, 'n' is signed (ssize_t), and 'howMany' is unsigned (size_t), and
    so compilers will promote 'n' to the unsigned type, causing this
    conditional to fail when n is -1. As a result, all of the relevant log
    messages are skipped, and the data in the dumpstream gets corrupted
    (we skip a block of data, and our 'howFar' offset goes back by 1). So
    this can result in rare silent data corruption in volume dumps, which
    can occur during volume releases, moves, etc.
    
    To fix all of this, remove this bizarre NUL-padding behavior in the
    volserver. Instead:
    
    - For actual errors from pread(), return an error, like we do for I/O
      errors in most other code paths.
    
    - For short reads, just write out the amount of data we actually read,
      and keep going.
    
    - For premature EOF, treat it like a pread() error, but log a slightly
      different message.
    
    For the 'voldump' utility, the padding behavior can make sense if a
    user is trying to recover volume data offline in a disaster recovery
    scenario. So for voldump, add a new switch (-pad-errors) to enable the
    padding behavior, but change the default behavior to bail out on
    errors.
    
    Reviewed-on: https://gerrit.openafs.org/14255
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 4498bd8179e5e93a33468be3c8e7a30e569d560a)
    
    Change-Id: Idf89d70c9d4d650dbf7b73e67c5b71b9bab7c3f4
    Reviewed-on: https://gerrit.openafs.org/14367
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 9947625a1d67b4ffdc0582e9081000e34be2b46b
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri May 15 12:01:44 2020 -0400

    vos: avoid CreateVolume when restoring over an existing volume
    
    Currently, the UV_RestoreVolume2 function always attempts to create a
    new volume, even when doing a incremental restore over an existing
    volume.  When the volume already exists, the volume creation operation
    fails on the volume server with a VVOLEXISTS error. The client will then
    attempt to obtain a transaction on the existing volume. If a transaction
    is obtained, the incremental restore operation will proceed. If a full
    restore is being done, the existing volume is removed and a new empty
    volume is created.
    
    Unfortunately, the failed volume creation is logged to by the volume
    server, and so litters the log file with:
    
        Volser: CreateVolume: Unable to create the volume; aborted, error code 104
    
    To avoid polluting the volume server log with these messages, reverse
    the logic in UV_RestoreVolume2. Assume the volume already exists and try
    to get the transaction first when doing an incremental restore. Create a
    new volume if the transaction cannot be obtained because the volume is
    not present.  When doing a full restore, remove the existing volume, if
    one exists, and then create a new empty volume.
    
    Reviewed-on: https://gerrit.openafs.org/14208
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
    Tested-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f5051b87a56b3a4f7fd7188cbd16a663eee8abbf)
    
    Change-Id: I422b81e0c800ff655ac8851b2872f4d7160d79a8
    Reviewed-on: https://gerrit.openafs.org/14326
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 967aa95fe23f98c911b8a618132442159eda3f77
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Wed Apr 29 05:10:05 2020 +0000

    rxkad: Use krb5_enctype_keysize in tkt_DecodeTicket5
    
    Inside tkt_DecodeTicket5 (rxkad/ticket5.c) function, keysize is calculated
    using krb5_enctype_keybits and then dividing number of bits by 8. For 3DES
    number of keybits are 168, so keysize comes out to 21(168/8). However
    actual keysize of 3DES key is 24. This keysize is passed to
    _afsconf_GetRxkadKrb5Key where keysize comparison happens, since there is
    keysize mismatch it returns AFSCONF_BADKEY.
    
    To fix this issue get keysize from krb5_enctype_keysize function instead
    of krb5_enctype_keybits. Thanks to John Janosik (jpjanosi@us.ibm.com)
    for analyzing and fixing this issue.
    
    Reviewed-on: https://gerrit.openafs.org/14203
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 5d53ed0bdab6fea6d2426691bdef2b6f9cb7f2fe)
    
    Change-Id: I16cd7a803a139802671a8045dac09e10ef4ad6cb
    Reviewed-on: https://gerrit.openafs.org/14325
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 28e96b954fe17810d1ebdd9fdd4702511e870a67
Author: Jan Iven <iven.jan@gmail.com>
Date:   Tue Sep 1 14:51:25 2020 +0200

    ptserver: Remove duplicate ubik_SetLock in listSuperGroups
    
    It looks like a call to ubik_SetLock(.. LOCKREAD) was left in
    place in listSuperGroups after locking was moved to ReadPreamble
    in commit a6d64d70 (ptserver: Refactor per-call ubik initialisation)
    When compiled with 'supergroups', and once contacted by
    "pts mem -expandgroups ..", ptserver will therefore abort() with
    Ubik: Internal Error: attempted to take lock twice
    This patch removes the superfluous ubik_SetLock.
    
    FIXES 135147
    
    Reviewed-on: https://gerrit.openafs.org/14338
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 696f2ec67b049639abf04905255a7d6173dbb19e)
    
    Change-Id: I62bfe44e374b398278658b61f2ecf9a66fab18ae
    Reviewed-on: https://gerrit.openafs.org/14345
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit c7a3154382376ca2e5effdfed2c447c86b9f6eed
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Wed Jul 1 21:50:09 2020 -0400

    redhat: Add make to the dkms-openafs pre-requirements
    
    If `make` is not installed before dkms-openafs, the OpenAFS kernel
    module is not built during the dkms-openafs package installation.
    
    The failure happens in the "checking if linux kernel module build works"
    configure step, which invokes `make` to check the linux buildsystem.
    configure fails when `make` is not available, and gives the unhelpful
    suggestion (in this case) of configuring with --disable-kernel module.
    
    Running the configure.log in the dkms build directory shows:
    
        configure:7739: checking if linux kernel module build works
        make -C /lib/modules/4.18.0-193.6.3.el8_2.x86_64/build M=/var/lib/dkms/openafs/...
        ./configure: line 7771: make: command not found
        configure: failed using Makefile:
    
    Avoid this build failure by adding `make` to the list of dkms-openafs
    package pre-requirements.
    
    Reviewed-on: https://gerrit.openafs.org/14266
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit e61ab9353e99d3298815296abf6b02c50ebe3df0)
    
    Change-Id: I9b2bb73acabfabc1cf8b5514c8aa66572cc96066
    Reviewed-on: https://gerrit.openafs.org/14314
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ddaf6a74ff3e0aeb4c8b2b15886eaa5c90db59bf
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Aug 28 10:32:01 2020 -0600

    INSTALL: document the minimum Linux kernel level
    
    The change associated with gerrit #14300 removed support for older
    Linux kernels (2.6.10 and earlier).
    
    The commit 'Import of code from autoconf-archive' (d8205bbb4) introduced
    a check for Autoconf 2.64.  Autoconf 2.64 was released in 2009.
    
    The commit 'regen.sh: Use libtoolize -i, and .gitignore generated
    build-tools' (a7cc505d3) introduced a dependency on libtool's  '-i'
    option.  Libtool supported the '-i' option with libtool 1.9b in 2004.
    
    Update the INSTALL instructions to document a minimum Linux kernel
    level and the minimum levels for autoconf and libtool.
    
    Notes: RHEL4 (EOL in 2017) had a 2.6.9 kernel and RHEL5 has a 2.6.18
    kernel. RHEL5 has libtool 1.5.22 and autoconf 2.59, RHEL6 has libtool
    2.2.6 and autoconf 2.63, and RHEL7 has libtool 2.4.2 and autoconf 2.69.
    
    Reviewed-on: https://gerrit.openafs.org/14305
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 16bae98ec525fa013514fb46398df682d7637ae0)
    
    Change-Id: I7aaf434928204df77851dd2d651d43b86f5b53d2
    Reviewed-on: https://gerrit.openafs.org/14331
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fee39617c350623dc659e7a21287a1791bdff5d2
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Wed Apr 1 22:59:38 2020 -0500

    vos: Print "done" in non-verbose 'vos remsite'
    
    Currently, 'vos remsite' always prints the message "Deleting the
    replication site for volume %lu ...", and then calls VDONE if the
    operation is successful. VDONE prints the trailing "done", but only if
    -verbose is turned on, and so if -verbose is not specified, the output
    of 'vos remsite' looks broken:
    
        $ vos remsite fs1 vicepa vol.foo
        Deleting the replication site for volume 1234 ...Removed replication site fs1 /vicepa for volume vol.foo
    
    To fix this, unconditionally print the trailing "done", instead of
    going through VDONE, so 'vos remsite' output now looks like this:
    
        $ vos remsite fs1 vicepa vol.foo
        Deleting the replication site for volume 1234 ... done
        Removed replication site fs1 /vicepa for volume vol.foo
    
    Reviewed-on: https://gerrit.openafs.org/14127
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit f16d40ad26df3ec871f8c73952594ad2e723c9b4)
    
    Change-Id: I4cd7cb2156391004e57cd42437d7174a6bd70992
    Reviewed-on: https://gerrit.openafs.org/14311
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ff5b64d074376992d0be02e19b4da789c20d6bab
Author: Marcio Barbosa <mbarbosa@sinenomine.net>
Date:   Thu Feb 13 00:39:00 2020 -0300

    vos: take RO volume offline during convertROtoRW
    
    The vos convertROtoRW command converts a RO volume into a RW volume.
    Unfortunately, the RO volume in question is not set as "out of service"
    during this process. As a result, accesses to the volume being converted
    can leave volume objects in an inconsistent state.
    
    Consider the following scenario:
    
    1. Create a volume on host_b and add replicas on host_a and host_b.
    
    $ vos create host_b a vol_1
    $ vos addsite host_b a vol_1
    $ vos addiste host_a a vol_1
    
    2. Mount the volume:
    
    $ fs mkmount /afs/.mycell/vol_1 vol_1
    $ vos release vol_1
    $ vos release root.cell
    
    3. Shutdown dafs on host_b:
    
    $ bos shutdown host_b dafs
    
    4. Remove RO reference to host_b from the vldb:
    
    $ vos remsite host_b a vol_1
    
    5. Attach the RO copy by touching it:
    
    $ fs flushall
    $ ls /afs/mycell/vol_1
    
    6. Convert RO copy to RW:
    
    $ vos convertROtoRW host_a a vol_1
    
    Notice that FSYNC_com_VolDone fails silently (FSYNC_BAD_STATE), leaving
    the volume object for the RO copy set as VOL_STATE_ATTACHED (on success,
    this volume should be set as VOL_STATE_DELETED).
    
    7. Add replica on host_a:
    
    $ vos addsite host_a a vol_1
    
    8. Wait until the "inUse" flag of the RO entry is cleared (or force this
    to happen by attaching multiple volumes).
    
    9. Release the volume:
    
    $ vos release vol_1
    
    Failed to start transaction on volume 536870922
    Volume not attached, does not exist, or not on line
    Error in vos release command.
    Volume not attached, does not exist, or not on line
    
    To fix this problem, take the RO volume offline during the vos
    convertROtoRW operation.
    
    Reviewed-on: https://gerrit.openafs.org/14066
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 32d35db64061e4102281c235cf693341f9de9271)
    
    Change-Id: Ie4cfab2f04a8859ddfcaece371198ac544066770
    Reviewed-on: https://gerrit.openafs.org/14310
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 696d9ce83e3556bda2d3945326937c63dd3560ed
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Tue Apr 19 20:46:33 2016 -0400

    ubik: positional io for db reads and writes
    
    The ubik library was written before positional i/o was available and
    issues an lseek system call for each database file read and write.  This
    change converts the ubik database accesses to use positional i/o on
    platforms where pread and pwrite are available, in order to reduce
    system call load.
    
    The new inline uphys_pread and uphys_pwrite functions are supplied on
    platforms which do not supply pread and pwrite. These functions fall
    back to non-positional i/o. If these symbols are present in the database
    server binary then the server process will continue to call lseek before
    each read and write access of the database file.
    
    This change does not affect the whole-file database synchronization done
    by ubik during database recovery (via the DISK_SendFile and DISK_GetFile
    RPCs), which still uses non-positional i/o. However, that code does not
    share file descriptors with the phys.c code, so there is no possibility
    of mixing positional and non-positional i/o on the same FDs.
    
    Reviewed-on: https://gerrit.openafs.org/12272
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit f62fb17b3cf1c886f8cfc2fabe9984070dd3eec4)
    
    Change-Id: Iccc8f749c89659f4acebd74a1115425f69610ba8
    Reviewed-on: https://gerrit.openafs.org/14142
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fffd6e07c87e36cd9a4a36858c3df0c282622195
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Wed Apr 20 18:17:16 2016 -0400

    ubik: remove unnecessary lseeks in uphys_open
    
    The ubik database file access layer has a file descriptor cache to avoid
    reopening the database file on each file access.  However, the file
    offset is reset with lseek on each and every use of the cached file
    descriptor, and the file offset is set twice when reading or writing
    data records.
    
    This change removes unnecessary and duplicate lseek system calls to
    reduce the system call load.
    
    Reviewed-on: https://gerrit.openafs.org/12271
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 6892bfbd701899281b34ee337637d438c7d8f8c6)
    
    Change-Id: I5ea7857796d94eb5b659d868e79b9fea2411f301
    Reviewed-on: https://gerrit.openafs.org/14141
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@gmail.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 438bc2c4caf96485e12eda9e7591fc4bd887ebad
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Nov 9 12:47:57 2017 -0600

    asetkey: Add new 'delete' command variants
    
    The current 'delete' command from asetkey only lets the user delete
    old-style rxkad keys. Add a couple of new variants to allow specifying
    the key type and subtype, so the user can delete specific key types
    and enctypes if they want.
    
    Reviewed-on: https://gerrit.openafs.org/12767
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit 5120409cc998284f2fb0467c2f88030976140341)
    
    Change-Id: I8c762839b50f4faf5e583fb5c510bf2ff9dd2259
    Reviewed-on: https://gerrit.openafs.org/14293
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 1c395cd1bcf5770f70dce36ef29f9bd7ba98acaa
Author: Kailas Zadbuke <kailashsz@in.ibm.com>
Date:   Thu May 7 23:55:39 2020 -0400

    salvaged: Fix "-parallel all<number>" parsing
    
    In salavageserver -parallel option takes "all<number>" argument.
    However the code does not parse the numeric part correctly. Due
    to this, only single instance of salvageserver process was running
    even if we provide the larger number with "all" argument.
    
    With this fix, numeric part of "all" argument will be parsed
    correctly and will start required number of salvageserver instances.
    
    Reviewed-on: https://gerrit.openafs.org/14201
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 4512d04a9b721cd9052c0e8fe026c93faf6edb9e)
    
    Change-Id: I8910fb514986a404b22256e8a514955a684c8a27
    Reviewed-on: https://gerrit.openafs.org/14285
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 38f7e123c33c1c11eb275e0619080ee874244afd
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Tue Jun 16 15:20:20 2020 -0600

    tests: Use usleep instead of nanosleep
    
    Commit "Build tests by default" 68f406436cc21853ff854c514353e7eb607cb6cb
    changes the build so tests are always built.
    
    On Solaris 10 the build fails because nanosleep is in librt, which we do
    not link against.
    
    Replace nanosleep with usleep.  This avoids introducing extra configure
    tests just for Solaris 10.
    
    Note that with Solaris 11 nanosleep was moved from librt to libc, the
    standard C library.
    
    Reviewed-on: https://gerrit.openafs.org/14244
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 22a66e7b7e1d73437a8c26c2a1b45bc4ef214e77)
    
    Change-Id: Ic24c5a149451955b5c130e7b36cec27e02688d83
    Reviewed-on: https://gerrit.openafs.org/14291
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 264d6b786c2fd0aff0e4abe835e42868f936afce
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Mar 24 11:59:48 2020 -0500

    tests: Wait for server start in auth/superuser-t
    
    The auth/superuser-t test runs an Rx server and client in two child
    processes. If the client process tries to contact the server before
    the server has started listening on its port, some tests involving
    RPCs can fail (notably test 39, "Can run a simple RPC").
    
    Normally if we try to contact a server that's not there, Rx will try
    resending its packets a few times, but on Linux with AFS_RXERRQ_ENV,
    if the port isn't open at all, we can get an ICMP_PORT_UNREACH error,
    which causes the relevant Rx call to die immediately with
    RX_CALL_DEAD.
    
    This means that if the auth/superuser-t client is only just a bit
    faster than the server starting up, tests can fail, since the server's
    port is not open yet.
    
    To avoid this, we can wait until the server's port is open before
    starting the client process. To do this, have the server process send
    a SIGUSR1 to the parent after rx_Init() is called, and have the parent
    process wait for the SIGUSR1 (waiting for a max of 5 seconds before
    failing). This should guarantee that the server's port will be open by
    the time the client starts running.
    
    Note that before commit 086d1858 (LINUX: Include linux/time.h for
    linux/errqueue.h), AFS_RXERRQ_ENV was mistakenly disabled on Linux
    3.17+, so this issue was probably not possible on recent Linux before
    that commit.
    
    Reviewed-on: https://gerrit.openafs.org/14109
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit 66d0f91791695ac585f0511d0dadafd4e570b1bf)
    
    Change-Id: Ia6c06ca9a05e33b3bc35238d9c0d18e7ff339438
    Reviewed-on: https://gerrit.openafs.org/14290
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit eaa552d27074cd7e1c862d606916b063e6d89a27
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Dec 31 12:04:48 2019 -0600

    tests: Introduce afstest_GetProgname
    
    Currently, in tests/volser/vos-t.c we call afs_com_err as
    "authname-t", which is clearly a mistake during some code refactoring
    (introduced in commit 2ce3fdc5, "tests: Abstract out code to produce a
    Ubik client").
    
    We could just change this to "vos-t", but instead of specifying
    constant strings everywhere, change this to figure out what the
    current command is called, and just use that. Put this code into a new
    function, afstest_GetProgname, and convert existing tests to use that
    instead of hard-coding the program name given to afs_com_err.
    
    Reviewed-on: https://gerrit.openafs.org/13991
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit a21a2f8edb79d6190976e920a9a90d0878411146)
    
    Change-Id: I3d410d6de132f8a0fffeb9cce32a912fe3bbdc20
    Reviewed-on: https://gerrit.openafs.org/14289
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fe57174d84cab19a13eea9a8f31f0ac71c8cf838
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Wed Aug 5 09:23:36 2020 -0600

    butc: fix int to float conversion warning
    
    Building with clang-10 results in 2 warnings/errors associated with
    with trying to convert 0x7fffffff to a floating point value.
    
        tcmain.c:240:18: error: implicit conversion from 'int' to 'float'
                     changes value from 2147483647 to 2147483648 [-Werror,
                     -Wimplicit-int-float-conversion]
        if ((total > 0x7fffffff) || (total < 0))    /* Don't go over 2G */
    
    and the same conversion warning on the statement on the following line:
        total = 0x7fffffff;
    
    Use floating point and decimal constants instead of the hex constants.
    
    For the test, use 2147483648.0 which is cleanly represented by a float.
    Change the comparison in the test from '>' to '>='.
    
    If the total value exceeds 2G, just assign the max value directly to the
    return variable.
    
    Reviewed-on: https://gerrit.openafs.org/14277
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 37b55b30c65d0ab8c8eaabfda0dbd90829e2c46a)
    
    Change-Id: I16e0acd893049b01a2c5e4c7e71de3fa40e28d3e
    Reviewed-on: https://gerrit.openafs.org/14299
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit e7902252f15acfc28453c531f6fa3b29c9c91b92
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Aug 21 10:37:51 2020 -0600

    LINUX 5.9: Remove HAVE_UNLOCKED_IOCTL/COMPAT_IOCTL
    
    Linux-5.9-rc1 commit 'fs: remove the HAVE_UNLOCKED_IOCTL and
    HAVE_COMPAT_IOCTL defines' (4e24566a) removed the two referenced macros
    from the kernel.
    
    The support for unlocked_ioctl and compat_ioctl were introduced in
    Linux 2.6.11.
    
    Remove references to HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL using
    the assumption that they were always defined.
    
    Notes:
    
    With this change, building against kernels 2.6.10 and older will fail.
    RHEL4 (EOL in March 2017) used a 2.6.9 kernel.  RHEL5 uses a 2.6.18
    kernel.
    
    In linux-2.6.33-rc1 the commit messages for "staging: comedi:
    Remove check for HAVE_UNLOCKED_IOCTL" (00a1855c) and "Staging: comedi:
    remove check for HAVE_COMPAT_IOCTL" (5d7ae225) both state that all new
    kernels have support for unlocked_ioctl/compat_ioctl so the checks can
    be removed along with removing support for older kernels.
    
    Reviewed-on: https://gerrit.openafs.org/14300
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 13a49aaf0d5c43bce08135edaabb65587e1a8031)
    
    Change-Id: I6dc5ae5b32031641f4a021a31630390a91d834fe
    Reviewed-on: https://gerrit.openafs.org/14315
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 99232fa48020bde90f6b245da4374bc63399654f
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Wed Aug 5 09:19:02 2020 -0600

    afs: Set AFS_VFSFSID to a numerical value
    
    Currently when UKERNEL is defined, AFS_VFSFSID is always set to
    AFS_MOUNT_AFS, which is a string for many platforms for UKERNEL.
    
    Update src/afs/afs.h to insure that the define for AFS_VFSFSID is a
    numeric value when building UKERNEL.
    
    Clean up the preprocessor indentation in src/afs/afs.h in the area
    around the AFS_VFSFSID defines.
    
    Thanks to adeason@sinenomine.net for pointing out a much easier solution
    for resolving this problem.
    
    Reviewed-on: https://gerrit.openafs.org/14279
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 446457a1240b88fd94fc34ff5715f2b7f2f3ef12)
    
    Change-Id: Ic0f9c2f1f4baeb9f99da19e1187f1bc9f5d7f824
    Reviewed-on: https://gerrit.openafs.org/14297
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 7e2a62fb594a7713a5c694b9e0401b5e3c2648c8
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Wed Aug 5 09:18:49 2020 -0600

    afs: Avoid using logical OR when setting f_fsid
    
    Building with clang-10 produces the warning/error message
        warning: converting the result of '<<' to a boolean always evaluates
        to true [-Wtautological-constant-compare]
    for the expression
        abp->f_fsid = (AFS_VFSMAGIC << 16) || AFS_VFSFSID;
    
    The message is because a logical OR '||' is used instead of a bitwise
    OR '|'.  The result of this expression will always set the f_fsid
    member to a 1 and not the intended value of AFS_VFSMAGIC combined with
    AFS_VFSFSID.
    
    Update the expression to use a bitwise OR instead of the logical OR.
    
    Note: This will change value stored in the f_fsid that is returned from
    statfs.
    
    Using a logical OR has existed since OpenAFS 1.0 for hpux/solaris and in
    UKERNEL since OpenAFS 1.5 with the commit 'UKERNEL: add uafs_statvfs'
    b822971a.
    
    Reviewed-on: https://gerrit.openafs.org/14292
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit c56873bf95f6325b70e63ed56ce59a3c6b2b753b)
    
    Change-Id: I2e3fe6a84ef6ce73fff933f137d4806efefa5949
    Reviewed-on: https://gerrit.openafs.org/14298
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit fc32922236122b9013ed9bdedda8c54c2e8c75d8
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri May 1 15:02:08 2020 -0500

    vlserver: Return error when growing beyond 2 GiB
    
    In the vlserver, when we add a new vlentry or extent block, we grow
    the VLDB by doing something like this:
    
        vital_header.eofPtr += sizeof(item);
    
    Since we don't check for overflow, and all of our offset-related
    variables are signed 32-bit integers, this can cause some odd behavior
    if we try to grow the database to be over 2 GiB in size.
    
    To avoid this, change the two places in vlserver code that grow the
    database to use a new function, grow_eofPtr(), which checks for 31-bit
    overflow. If we are about to overflow, log a message and return an
    error.
    
    See the following for a specific example of our "odd behavior" when we
    overflow the 2 GiB limit in the VLDB:
    
    With 1 extent block, we can create 14509076 vlentries successfully. On
    the 14509077th vlentry, we'll attempt to write the entry to offset
    2147483560 (0x7FFFFFA8). Since a vlentry is 148 bytes long, we'll
    write all the way through offset 2147483707 (0x8000003B), which is
    over the 31-bit limit.
    
    In the udisk subsystem, this results in writing to page numbers
    2097151, and -2097152 (since our ubik pages are 1k, and going over the
    31-bit limit causes us to treat offsets as negative). These pages
    start at physical offsets 2147482688 (0x7FFFFC40) and -2147483584
    (-0x7FFFFFC0) in our vldb.DB0 (where offset is page*1024+64).
    
    Modifying each of these pages involves reading in the existing page
    first, modifying the parts we are changing, and writing it back. This
    works just fine for 2097151, but of course fails for -2097152. The
    latter fails in DReadBuffer when eventually our pread() fails with
    EINVAL, and causes ubik to log the message:
    
        Ubik: Error reading database file: errno=22
    
    But when DReadBuffer fails, DReadBufferForWrite assumes this is due to
    EOF, and just creates a new buffer for the given page (DNewBuffer).
    So, the udisk_write() call ultimately succeeds.
    
    When we go to flush the dirty data to disk when committing the
    transaction, after we have successfully written the transaction log,
    DFlush() fails for the -2097152 page when the pwrite() call eventually
    fails with EINVAL, causing ubik to panic, logging the messages:
    
        Ubik PANIC:
        Writing Ubik DB modifications
    
    When the vlserver gets restarted by bosserver, we then process the
    transaction log, and perform the operations in the log before starting
    up (ReplayLog). The log records the actual data we wrote, not split
    into pages, and the log-replaying code writes directly to the db
    usying uphys_write instead of udisk_write. So, because of this, the
    write actually succeeds when replaying the log, since we just write
    148 bytes to offset 2147483624 (0x7FFFFFE8), and no negative offsets
    are used.
    
    The vlserver will then be able to run, but will be unable to read that
    newly-created vlentry, since it involves reading a ubik page beyond
    the 31-bit boundary. That means trying to lookup that entry will fail
    with i/o errors, and as well as any entry on the same hash chains as
    the new entry (since the new entry will be added to the head of the
    hash chain). Listing all entries in the database will also just show
    an empty database, since our vital_header.eofPtr will be negative, and
    we determine EOF by comparing our current blockindex to the value in
    eofPtr.
    
    Reviewed-on: https://gerrit.openafs.org/14180
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit d01398731550b8a93b293800642c3e1592099114)
    
    Change-Id: I72302a8c472b3270e99e58a573f5cf25dd34b9c5
    Reviewed-on: https://gerrit.openafs.org/14288
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 03979eaa174de0cff188af451806fb7ae10d3a62
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Tue Apr 7 13:15:31 2020 -0500

    vlserver: Correctly pad nvlentry for "O" RPCs
    
    For our old-style "O" RPCs (e.g. VL_CreateEntry, instead of
    VL_CreateEntryN), vlserver calls vldbentry_to_vlentry to convert to
    the internal 'struct nvlentry' format. After all of the sites have
    been copied to the internal format, we fill the remaining sites by
    setting the serverNumber to BADSERVERID. For nvldbentry_to_vlentry, we
    do this for NMAXNSERVERS sites, but for vldbentry_to_vlentry, we do
    this for OMAXNSERVERS.
    
    The thing is, both functions are filling in entries for a 'struct
    nvlentry', which has NMAXNSERVERS 'serverNumber' entries. So for
    vldbentry_to_vlentry, we are skipping setting the last few sites
    (specifically, NMAXNSERVERS-OMAXNSERVERS = 13-8 = 5).
    
    This can easily cause our O-style RPCs to write out entries to disk
    that have uninitialized sites at the end of the array. For example, an
    entry with one site should have server numbers that look like this:
    
        serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255}
    
    That is, one real serverid (a '1' here), followed by twelve
    BADSERVERIDs.
    
    But for a VL_CreateEntry call, the 'struct nvlentry' is zeroed out
    before vldbentry_to_vlentry is called, and so the server numbers in
    the written entry look like this:
    
        serverNumber = {1, 255, 255, 255, 255, 255, 255, 255, 0, 0, 0, 0, 0}
    
    That is, one real serverid (a '1' here), followed by seven
    BADSERVERIDs, followed by five '0's.
    
    Most of the time, this is not noticeable, since our code that reads in
    entries from disk stops processing sites when we encounter the first
    BADSERVERID site (see vlentry_to_nvldbentry). However, if the entry
    has 8 sites, then none of the entries will contain BADSERVERID, and so
    we will actually process the trailing 5 bogus sites. This would appear
    as 5 extra volume sites for a volume, most likely all for the same
    server.
    
    For VL_CreateEntry, the vlentry struct is always zeroed before we use
    it, so the trailing sites will always be filled with 0. For
    VL_ReplaceEntry, the trailing sites will be unchanged from whatever
    was read in from the existing disk entry.
    
    To fix this, just change the relevant loop to go through NMAXNSERVERS
    entries, so we actually go to the end of the serverNumber (et al)
    array.
    
    This may appear similar to commit ddf7d2a7 (vlserver: initialize
    nvlentry elements after read). However, that commit fixed a case
    involving the old vldb database format (which hopefully is not being
    used). This commit fixes a case where we are using the new vldb
    database format, but with the old RPCs, which may still be used by old
    tools.
    
    Reviewed-on: https://gerrit.openafs.org/14139
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7e41ee0bd50d39a356f0435ff370a0a7be40306f)
    
    Change-Id: I68ecc41e7268efd0424e6c129aa914cd04115b59
    Reviewed-on: https://gerrit.openafs.org/14287
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 986ee1fd422d1608553af5a6a02bd60349b864ac
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jun 19 08:01:14 2020 -0600

    afs: Avoid panics on failed return from afs_CFileOpen
    
    afs_CFileOpen is a macro that invokes the open "method" of the
    afs_cacheOps structure, and for disk caches the osi_UFSOpen function is
    used.
    
    Currently osi_UFSOpen will panic if there is an error encountered while
    opening a file.
    
    Prepare to handle osi_UFSOpen function returning a NULL instead of
    issuing a panic (future commit).
    
    Update callers of afs_CFileOpen to test for an error and to return an
    error instead of issuing a panic.
    
    While this commit eliminates some panics, it does not address some of the
    more complex cases associated with errors from afs_CFileOpen.
    
    Reviewed-on: https://gerrit.openafs.org/14241
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit d2d27f975df13c3833898611dacff940a5ba3e2a)
    
    Change-Id: Ia30711748b3cffd56eb3120961aa1747dfae0f23
    Reviewed-on: https://gerrit.openafs.org/14286
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a00fe9fd4253b2436ae649b05b329d0d52c8b6f6
Author: Yadavendra Yadav <yadayada@in.ibm.com>
Date:   Thu Mar 5 07:21:55 2020 +0000

    LINUX: Initialize CellLRU during osi_Init
    
    When OpenAFS kernel module gets loaded, it will create certain entries
    in "proc" filesystem. One of those entries is "CellServDB", in case
    we read "/proc/fs/openafs/CellServDB" without starting "afsd" it will
    result in crash with NULL pointer deref. The reason for crash is
    CellLRU has not been initialized yet (since "afsd" is not started)
    i.e afs_CellInit is not yet called, because of this "next" and "prev"
    pointers will be NULL. Inside "c_start()" we do not check for NULL
    pointer while traversing CellLRU and this causes crash.
    
    To avoid this initialize CellLRU during module intialization.
    
    Reviewed-on: https://gerrit.openafs.org/14093
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 8d90a9d27b0ef28ddcdd3eb041c8a9d019b84b50)
    
    Change-Id: I9ed97d3751943331c9d9bc9dfc73acc24231187b
    Reviewed-on: https://gerrit.openafs.org/14284
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 6824d45c2ab83e52350c3f366e4cb6f1eb263088
Author: Kailas Zadbuke <kailashsz@in.ibm.com>
Date:   Wed Jun 3 15:44:08 2020 +0530

    util: Handle serverLogMutex lock across forks
    
    If a process forks when another thread has serverLogMutex locked, the
    child process inherits the locked serverLogMutex. This causes a deadlock
    when code in the child process tries to lock serverLogMutex, since we
    can never unlock serverLogMutex because the locking thread no longer
    exists. This can happen in the salvageserver, since the salvageserver
    locks serverLogMutex in different threads, and forks to handle salvage
    jobs.
    
    To avoid this deadlock, we register handlers using pthread_atfork()
    so that the serverLogMutex will be held during the fork. The fork will
    be blocked until the worker thread releases the serverLogMutex. Hence the
    serverLogMutex will be held until the fork is complete and it will be
    released in the parent and child threads.
    
    Thanks to Yadavendra Yadav(yadayada@in.ibm.com) for working with me
    on this issue.
    
    Reviewed-on: https://gerrit.openafs.org/14239
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    (cherry picked from commit e44d6441c8786fdaaa1fad1b1ae77704c12f7d60)
    
    Change-Id: I09c04c0bd99b10433857ccdaeb4ee6a4cd50f768
    Reviewed-on: https://gerrit.openafs.org/14283
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Kailas Zadbuke <kailashsz@in.ibm.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 179a418ea5063785a23e4faf35134f063a6f3e1c
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri Mar 13 13:00:35 2020 -0500

    LINUX: Properly revert creds in osi_UFSTruncate
    
    Commit cd3221d3 (Linux: use override_creds when available) caused us
    to force the current process's creds to the creds of afsd during
    osi_file.c file ops, to avoid access errors in some cases.
    
    However, in osi_UFSTruncate, one code path was missed to revert our
    creds back to the original user's creds: when the afs_osi_Stat call
    fails or deems the truncate unnecessary. In this case, the calling
    process keeps the creds for afsd after osi_UFSTruncate returns,
    causing our subsequent access-checking code to think that the current
    process is in the same context as afsd (typically uid 0 without a
    pag).
    
    This can cause the calling process to appear to transiently have the
    same access as non-pag uid 0; typically this will be unauthenticated
    access, but could be authenticated if uid 0 has tokens.
    
    To fix this, modify the early return in osi_UFSTruncate to go through
    a 'goto done' destructor instead, and make sure we revert our creds in
    that destructor.
    
    Thanks to cwills@sinenomine.net for finding and helping reproduce the
    issue.
    
    Reviewed-on: https://gerrit.openafs.org/14098
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit 57b4f4f9be1e25d5609301c10f717aff32aef676)
    
    Change-Id: I714eb2dea9645ffe555f26b5d69707a7afbe8d81
    Reviewed-on: https://gerrit.openafs.org/14099
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ee578e92d9f810d93659a9805d0c12084fe2bb95
Author: Jeffrey Hutzelman <jhutz@cmu.edu>
Date:   Thu May 2 16:02:47 2019 -0400

    Linux: use override_creds when available
    
    Linux may perform some access control checks at the time of an I/O
    operation, rather than relying solely on checks done when the file is
    opened. In some cases (e.g. AppArmor), these checks are done based on
    the current tasks's creds at the time of the I/O operation, not those
    used when the file was open.
    
    Because of this, we must use override_creds() / revert_creds() to make
    sure we are using privileged credentials when performing I/O operations
    on cache files. Otherwise, cache I/O operations done in the context of
    a task with a restrictive AppArmor profile will fail.
    
    Reviewed-on: https://gerrit.openafs.org/13751
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit cd3221d3532a28111ad22d4090ec913cbbff40da)
    
    Change-Id: I8955ff6150462fecba9a10a8f99bce9ee8163435
    Reviewed-on: https://gerrit.openafs.org/14082
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Jeffrey Hutzelman <jhutz@cmu.edu>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit facff58b840a47853592510617ba7a1da2e3eaa9
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jul 3 10:35:06 2020 -0600

    LINUX 5.8: use lru_cache_add
    
    With Linux-5.8-rc1 commit 'mm: fold and remove lru_cache_add_anon() and
    lru_cache_add_file()' (6058eaec), the lru_cache_add_file function is
    removed since it was functionally equivalent to lru_cache_add.
    
    Replace lru_cache_add_file with lru_cache_add.
    
    Introduce a new autoconf test to determine if lru_cache_add is present
    
    For reference, the Linux changes associated with the lru caches:
    
      __pagevec_lru_add introduced before v2.6.12-rc2
    
      lru_cache_add_file introduced in v2.6.28-rc1
      __pagevec_lru_add_file replaces __pagevec_lru_add in v2.6.28-rc1
         vmscan: split LRU lists into anon & file sets (4f98a2fee)
    
      __pagevec_lru_add removed in v5.7 with a note to use lru_cache_add_file
         mm/swap.c: not necessary to export __pagevec_lru_add() (bde07cfc6)
    
      lru_cache_add_file removed in v5.8
         mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
          (6058eaec)
      lru_cache_add exported
         mm: fold and remove lru_cache_add_anon() and lru_cache_add_file()
          (6058eaec)
    
    Openafs will use:
      lru_cache_add on 5.8 kernels
      lru_cache_add_file from 2.6.28 through 5.7 kernels
      __pagevec_lru_add/__pagevec_lru_add_file on pre 2.6.28 kernels
    
    Reviewed-on: https://gerrit.openafs.org/14249
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Yadavendra Yadav <yadayada@in.ibm.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7d85ce221d6ccc19cf76ce7680c74311e4ed2632)
    
    Change-Id: Iba6ef4441687dbf60d227a708e2a032c2c0dc79f
    Reviewed-on: https://gerrit.openafs.org/14269
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 335f37be13d2ff954e4aeea617ee66502170805e
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jul 3 10:34:42 2020 -0600

    LINUX 5.8: do not set name field in backing_dev_info
    
    Linux-5.8-rc1 commit 'bdi: remove the name field in struct
    backing_dev_info' (1cd925d5838)
    
    Do not set the name field in the backing_dev_info structure if it is
    not available. Uses an existing config test
        'STRUCT_BACKING_DEV_INFO_HAS_NAME'
    
    Note the name field in the backing_dev_info structure was added in
    Linux-2.6.32
    
    Reviewed-on: https://gerrit.openafs.org/14248
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit d8ec294534fcdee77a2ccd297b4b167dc4d5573d)
    
    Change-Id: I3d9e18092db998a4c4f26bd63ee3b75383a53d4c
    Reviewed-on: https://gerrit.openafs.org/14268
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit d7fc5bf9bf031089d80703c48daf30d5b15a80ca
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Jul 3 10:33:51 2020 -0600

    LINUX 5.8: Replace kernel_setsockopt with new funcs
    
    Linux 5.8-rc1 commit 'net: remove kernel_setsockopt' (5a892ff2facb)
    retires the kernel_setsockopt function. In prior kernel commits new
    functions (ip_sock_set_*) were added to replace the specific functions
    performed by kernel_setsockopt.
    
    Define new config test 'HAVE_IP_SOCK_SET' if the 'ip_sock_set' functions
    are available. The config define 'HAVE_KERNEL_SETSOCKOPT' is no longer
    set in Linux 5.8.
    
    Create wrapper functions that replace the kernel_setsockopt calls with
    calls to the appropriate Linux kernel function(s) (depending on what
    functions the kernel supports).
    
    Remove the unused 'kernel_getsockopt' function (used for building with
    pre 2.6.19 kernels).
    
    For reference
        Linux 2.6.19 introduced kernel_setsockopt
        Linux 5.8 removed kernel_setsockopt and replaced the functionality
                  with a set of new functions (ip_sock_set_*)
    
    Reviewed-on: https://gerrit.openafs.org/14247
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit c48072b9800759ef1682b91ff1e962f6904a2594)
    
    Change-Id: I2724fad06b1882149d2066d13eced55eff5ee695
    Reviewed-on: https://gerrit.openafs.org/14267
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Laß <lass@mail.uni-paderborn.de>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 0f67e733e82a9001f3f9253c5e1880be845d537b
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Apr 2 13:27:50 2020 -0600

    LINUX: Include linux/time.h for linux/errqueue.h
    
    The configuration test for errqueue.h fails with an undefined structure
    error on a Linux 3.17 (or higher) system.  This prevents setting
    HAVE_LINUX_ERRQUEUE_H, which is used to define AFS_RXERRQ_ENV.
    
    Linux commit f24b9be5957b38bb420b838115040dc2031b7d0c (net-timestamp:
    extend SCM_TIMESTAMPING ancillary data struct) - which was picked up in
    linux 3.17 added a structure that uses the timespec structure.  After
    this commit, we need to include linux/time.h to pull in the definition
    of the timespec struct.
    
    Reviewed-on: https://gerrit.openafs.org/13950
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 086d185872da5f19447cf5ec7846e7ce5104563f)
    
    Change-Id: I67d01b11c5ea95b8b87832fc833f8fc850ade684
    Reviewed-on: https://gerrit.openafs.org/14130
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 5a14bd0abe83b580f0cc7a200ae963399ab7de5f
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Tue May 26 12:11:28 2020 -0600

    vol: Fix format-truncation warning with gcc-10.1
    
    Building with gcc-10.1 produces a warning (error if --enable-checking)
    in vol-salvage.c
    
    error: ‘%s’ directive output may be truncated writing up to 755 bytes
           into a region of size 255 [-Werror=format-truncation=]
      809 |     snprintf(inodeListPath, 255, "%s" OS_DIRSEP "salvage.inodes.%s.%d", tdir, name,
    
    Use strdup/asprintf to allocate the buffer dynamically instead of using
    a buffer with a hardcoded size.
    
    Reviewed-on: https://gerrit.openafs.org/14207
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit d73680c5f70ee5aeb634a9ec88bf1097743d0f76)
    
    Change-Id: I8d3bf244a70f723f585738905deea7ddfb1bb862
    Reviewed-on: https://gerrit.openafs.org/14232
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit d5fc5283e91ea94a67df8364a5b8bf8970ffe934
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Mon Oct 9 22:16:09 2017 -0400

    afsmonitor: remove unused LWP_WaitProcess
    
    Remove the unimplemented once-only flag and the unused LWP_WaitProcess
    call.
    
    Reviewed-on: https://gerrit.openafs.org/12745
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 7c27365ea24aed5787f6fc03f30f6085c78ece51)
    
    Change-Id: I3b61f9fb4f45564304b0e35878d3535a10e31d02
    Reviewed-on: https://gerrit.openafs.org/14226
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit a2eec64374d6b754b29c509b554573cb6e53eb46
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri May 22 12:16:48 2020 -0600

    Avoid duplicate definitions of globals
    
    GCC 10 changed a default flag from -fcommon to -fno-common.  See
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678 for some background.
    
    The change in gcc 10 results in build link-time errors. For example:
       ../../src/xstat/.libs/liboafs_xstat_cm.a(xstat_cm.o):(.bss+0x2050):
           multiple definition of `numCollections';
    
    Ensure that only one definition for global data objects exist and change
    references to use "extern" as needed.
    
    To ensure that future changes do not introduce duplicated global
    definitions, add the -fno-common flag to XCFLAGS when using the
    configure --enable-checking setting.
    
    [cwills@sinenomine.net: Note for 1.8.x: renamed terminationEvent
    to cm_terminationEvent/fs_terminationEvent instead of deleting it.]
    
    Reviewed-on: https://gerrit.openafs.org/14106
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 0e2072ae386d4111bef161eb955964b649c31386)
    
    Change-Id: I54ca61d372cf763e4a28c0b0829ea361219f6203
    Reviewed-on: https://gerrit.openafs.org/14217
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit 278592ef2d766c77de821b9da80359f24fec5b62
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Mon Jan 27 12:26:41 2020 -0500

    uss: more gcc9 truncation warning appeasement
    
    uss_procs_PickADir needs a larger buffer to avoid a truncation warning.
    While here, replace some magic numbers with existing symbols.
    
    Reviewed-on: https://gerrit.openafs.org/14049
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit 6c54bc9e121b923ec5fdd60ee510171987e55017)
    
    Change-Id: I5cb76a8a9b2a9b342a1ddae2f41ecab82f762326
    Reviewed-on: https://gerrit.openafs.org/14140
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>

commit ff07fa706e00f6dde13c58588d2f75e7fc26ecf5
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Fri Jan 10 09:06:38 2020 -0500

    tests: do not resolve addresses in vos/vl test
    
    The vos-t test adds a set of 10.* test addresses to a test vlserver and
    runs vos to read them back.  When the test is run in an environment
    where hosts have been assigned in the 10.* internal network, vos will resolve
    the addresses to hostnames and the test fails.  Pass the -noresolve
    option to vos for this test when checking for the expected list of
    addresses.
    
    Example test output before this commit:
    
        ./vos-t
        ...
        #   seen: 10.0.0.0
        10.0.0.1
        myhost.example.com
        10.0.0.3
        ...
        not ok 5 - vos output matches
    
    Reviewed-on: https://gerrit.openafs.org/14020
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    (cherry picked from commit dcf44ab5fc5c1f5e2e759ea4b6156f7e1faa4b7a)
    
    Change-Id: Ie2a6d97070fe47886a1ccf8c0ddf03012f805beb
    Reviewed-on: https://gerrit.openafs.org/14105
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>