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

