commit 84e6658efaf9b64292d1b386c51f91a75f792be1
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Thu Apr 30 12:22:08 2026 -0400

    Make OpenAFS 1.8.16
    
    Update version strings for the 1.8.16 release.
    
    Change-Id: I41e1e0a3305ca85d859fa6b876008a0c3432f88d
    Reviewed-on: https://gerrit.openafs.org/16786
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 083536eb89797be662229c0033f9a5b4f5089321
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Thu Apr 30 12:19:42 2026 -0400

    Update NEWS for OpenAFS 1.8.16
    
    Change-Id: I49e1f32d5d17fb5f86e08e86c1938065dd8c997a
    Reviewed-on: https://gerrit.openafs.org/16785
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 8507608e3f07b0c0e76062a29ebae12740406d28
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Wed Apr 15 16:49:50 2026 +0000

    RedHat: Add packaging support for Amazon Linux
    
    Add support to build RPMs for the Amazon Linux distribution.
    
    The 'amzn' macro is set when building on Amazon Linux. The values at
    this time can be '1', '2', or '2023', which indicate the major releases.
    Update our platform conditionals in the spec file and the custom
    openafs-kmodtool to support this macro.
    
    Amazon Linux 2023 added a "1:" epoch to the version of its kernel
    packages, which isn't visible in the 'uname -r' output. For example:
    
        $ uname -r
        6.1.166-197.305.amzn2023.x86_64
        $ rpm -q --provides kernel | grep kernel-x86_64
        kernel-x86_64 = 1:6.1.166-197.305.amzn2023
    
    We need to match that version in our various fields; for example, if we
    declare Requires for kernel "6.1.166-197.305.amzn2023" (without an
    epoch), we're requiring a version that doesn't exist, so our package is
    unusable. We must require kernel "1:6.1.166-197.305.amzn2023" instead.
    
    To fix this, introduce the `kernel_epoch` shell variable in
    `openafs-kmodtool` to support the kernel version epoch, and set it to
    "1:" for amzn2023.  The new "kernel_epoch" is not set for other
    RHEL-like distributions (e.g. RHEL, Fedora, Rocky, Alma Linux).
    
    Note: The kernel_epoch is not to be confused with the existing epoch
    macro. The latter is a placeholder for the openafs package version, not
    the kernel version.
    
    FIXES 135591
    FIXES 135592
    Reviewed-on: https://gerrit.openafs.org/16777
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Tested-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 88ac75b008aa38fc77ca96cf6caa9d7f20ea4167)
    
    Change-Id: I6668454d0faa22634e7ecf01cba29063dfd0cf6e
    Reviewed-on: https://gerrit.openafs.org/16783
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 9045e297006dab4bed9e66aa45d2a911fe8b810d
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Sat Apr 25 10:36:01 2026 -0400

    RedHat: Remove kmod debuginfo pkg on newer distros
    
    Starting with RHEL 8 and Fedora 28, building the kmod debuginfo package
    is done automaticaly when building the kmod package. Currently, we
    always define an explicit separate debuginfo package for the kmod, which
    is redundant, and generates numerous warnings because we're effectively
    making the same package twice. For example:
    
        $ make rpm
        [...]
        rpmbuild --rebuild [...] packages/openafs-*.src.rpm
        [...]
        package kmod-openafs-debuginfo already exists
        File listed twice: /usr/lib/debug
        File listed twice: /usr/lib/debug/.build-id/6b/160aa196a99d8416e273152499541bfbd8791b
        File listed twice: /usr/lib/debug/.build-id/6b/160aa196a99d8416e273152499541bfbd8791b.debug
        File listed twice: /usr/lib/debug/lib
        File listed twice: /usr/lib/debug/lib/modules
        File listed twice: /usr/lib/debug/lib/modules/6.12.0-124.49.1.el10_1.x86_64
        [...]
    
    Remove the explicit kmod debuginfo package for RHEL 8+ and Fedora 28+ to
    avoid these warnings.
    
    Reviewed-on: https://gerrit.openafs.org/16776
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit ab01859f59c89a4235d3d8de164ececa00d60960)
    
    Change-Id: I6122812831687b37d326de0f6d2de650c5d6d6fc
    Reviewed-on: https://gerrit.openafs.org/16782
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 8c3d856b94591328423e148773546c2684af90bd
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Sat Apr 25 19:56:21 2026 -0400

    RedHat: Remove macros in comment
    
    rpmbuild expands macros before processing comments, which is intentional
    but can lead to surprises.  Remove macros from the comment added in
    commit ece5b1727a94 (RedHat: Set source_date_epoch to the current system
    time) to fix the rpmbuild warning message:
    
       warning: Macro expanded in comment on line 17: %source_date_epoch_from_changelog to 1 and update the %changelog
    
    Reviewed-on: https://gerrit.openafs.org/16775
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 938b710347d198a33a03dfb1c5612109ed6837be)
    
    Change-Id: I245f35e08d20f2cf9b57b8c70fc873ec392d8a3c
    Reviewed-on: https://gerrit.openafs.org/16781
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 1ef1cf3b31c1c2452227cc49c551d0f50c07bc60
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Sat Apr 11 12:13:44 2026 -0400

    RedHat: Set source_date_epoch to the current system time
    
    Modern versions of rpmbuild (since 2016) support reproducible builds by
    extracting the timestamp of the last entry of the changelog to use as a
    build timestamp, called `source_date_epoch`. The `source_date_epoch`
    timestamp is used to clamp the modification times of the files generated
    (instead of the current system time), to set timestamps in the package
    metadata (e.g., BUILDTIME), and to set the SOURCE_DATE_EPOCH environment
    variable during the build.  The SOURCE_DATE_EPOCH environment variable is
    honored by the OpenAFS build system by embedding a timestamp in the
    version string displayed by `rxdebug -version`.
    
    Extracting the `source_date_epoch` timestamp from the %changelog works
    well for downstream packaging, but is not ideal for our in-tree spec
    file. Since this is used for development and as a reference for
    packagers, the %changelog is not updated for each release. As a result,
    the packages built with the in-tree spec file contain very old build
    dates.
    
    This change modifies our in-tree spec file to disable the default
    behavior of extracting the `source_date_epoch` timestamp from the
    changelog. Instead, set the `source_date_epoch` to the current system
    time by default. Support is also added to allow the builder to specify
    the `source_date_epoch` on the command line or in a macro file (e.g.,
    ~/.rpmmacros).
    
    For example, to specify the timestamp from a tag name:
    
        $ rpmbuild --define "source_date_epoch $(git log -1 --format=%ct openafs-stable-1_9_3pre1)" ...
    
    To specify the timestamp from the mtime of a file:
    
        $ rpmbuild --define "source_date_epoch $(date +%s -r path/to/filename)" ...
    
    Include a comment to encourage downstream packagers to set the
    `source_date_epoch_from_changelog` to 1 and update the %changelog on each
    release.
    
    Reviewed-on: https://gerrit.openafs.org/16772
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit ece5b1727a940e8185f0386b66e874ed0640909b)
    
    Change-Id: I08100fcb2c5fc7547de416026f790c9735e9bbaf
    Reviewed-on: https://gerrit.openafs.org/16780
    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: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 0b3d8b86df95e78aaa0c05e9439ccaf21d872077
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Tue Nov 11 15:10:32 2025 -0500

    Make OpenAFS 1.8.16pre1
    
    Update version strings for the 1.8.16pre1 release.
    
    Change-Id: I2f75a0ffd5c9aa6a68b1d4be70527402ecd1193a
    Reviewed-on: https://gerrit.openafs.org/16740
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>

commit e60980e977d9b8d6b407ff0c02d4c89968167f07
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Wed Apr 1 14:12:10 2026 -0600

    Update NEWS for OpenAFS 1.8.16pre1
    
    Change-Id: I0562b97e7dd64b4620280f068fd501ee630a37d3
    Reviewed-on: https://gerrit.openafs.org/16739
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: Benjamin Kaduk <kaduk@mit.edu>

commit 61a4b70259300c14b91d172e61d196f44648dfad
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Thu Feb 9 18:35:01 2023 -0600

    libtool: Make libfoo.krb depend on libfoo
    
    During parallel builds, we can run the final 'libtool --mode=link'
    step for, say, pam_afs.la and pam_afs.krb.la in parallel. When libtool
    runs --mode=link for these libraries, it effectively does the
    following (amongst many other steps):
    
    - rm -rf .libs/"$libname".*
    - mkdir .libs/"$libname".lax
    - mkdir .libs/"$libname".lax/libopr_pic.a
    
    The 'rm -rf' cleans up any lingering files from previous runs in the
    .libs dir (e.g. .libs/pam_afs.a, .libs/pam_afs.lai, etc etc). The
    '.lax' directory is used as a temporary space to extract object files
    in dependant libs. And of course it creates various other files in
    there named like .libs/pam_afs.lai.
    
    But if we're building a library called pam_afs.krb.la, then some of
    our temporary files will be named like .libs/pam_afs.krb.lax, which
    get deleted when building pam_afs.la when it deletes
    ".libs/pam_afs.*". So, if we build pam_afs.la while the libtool
    command for pam_afs.krb.la is using .libs/pam_afs.krb.lax, the
    temporary files can get deleted out from under us, causing rare
    confusing libtool errors. For example:
    
        /bin/sh ../../libtool --quiet --mode=link --tag=CC gcc  -rpath /usr/local/lib \
                -module -no-undefined -o pam_afs.la [...]
        /bin/sh ../../libtool --quiet --mode=link --tag=CC gcc  -rpath /usr/local/lib \
                -module -no-undefined -o pam_afs.krb.la [...]
        ../../libtool: line 1719: cd: .libs/pam_afs.krb.lax/libopr_pic.a: No such file or directory
        make[3]: *** [Makefile:76: pam_afs.krb.la] Error 1
        make[3]: *** Waiting for unfinished jobs....
    
    Fortunately, most of the libraries we build don't have dots in their
    name, and so avoid this issue. But we do have a few libraries that
    build a ".krb" variant, and so can be impacted by this. This includes
    pam_afs.krb, libauth.krb, and libkauth.krb.
    
    To make sure these libraries don't encounter this problem, make the
    .krb variant depend on the non-.krb variant, so the libraries aren't
    built in parallel.
    
    Reviewed-on: https://gerrit.openafs.org/15328
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    (cherry picked from commit d93871b054e814bf0d5b02dc0d06c17845ee4edd)
    
    Change-Id: I955d41d2e43440f201d81c544995109a89fe5df0
    Reviewed-on: https://gerrit.openafs.org/16758
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 3f4168147dd3905a24bcef445f5c9ac553ba5d69
Author: Mark Vitale <mvitale@sinenomine.net>
Date:   Wed Mar 25 16:20:30 2026 -0400

    macOS: Package some LWP binaries as x86_64 only
    
    Many commands built with LWP currently fail on macOS arm64 (Apple
    Silicon) on 1.8.x:
    
       $ fs mkmount <path> <volname>
       Segmentation fault: 11
       $ fs mkmount <path> <volname>
       Bus error: 10
    
    To avoid this, use the 'lipo' utility to convert a few LWP programs to
    "thin" x86_64 binaries when we build our macOS packages, if we're
    building universal binaries (ARCHFLAGS="-arch x86_64 -arch arm64").
    These will run fine on arm64 under automatic Rosetta2 x86_64 amulation,
    and do not exhibit the same issues with LWP. Save the original binaries
    in a "bin.orig" directory, so they are still available if needed. Do
    this for the following binaries:
    
    - bos
    - cmdebug
    - fs
    - xstat_cm_test
    - xstat_fs_test
    - backup
    
    This is a 1.8-only commit. On the master branch, this issue is moot
    because most binaries have been converted to pthreads in commits such as
    3ded79e52b (venus: Build fs and friends as pthreaded programs).
    Converting these programs to pthreads would be a rather large change in
    the middle of the stable 1.8 series, so at least for now, perform this
    smaller macOS-only targeted fix for 1.8 instead.
    
    Thanks to Ganesh Chaudhari <gangovind@in.ibm.com> for reporting the
    issue.
    
    Change-Id: Ib81d2ddf3ed11188442e22981de092be1101e0a7
    Reviewed-on: https://gerrit.openafs.org/16753
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 7e3397d4c1187ee691937b1bb73185d818af3c06
Author: Michael Meffie <mmeffie@sinenomine.net>
Date:   Mon Mar 23 19:50:56 2026 -0400

    Fix -Wdiscarded-qualifiers warnings from strrchr()
    
    In recent versions of GCC (e.g. GCC 14) and of glibc (e.g., 2.43), the
    strrchr() function has been updated to follow ISO C23 rules, which can
    trigger the discarded-qualifiers warning when the strrchr() input is a
    `const char *` but the function return is assigned to a type `char *`.
    
    Assigning this result to a `char *` discards the const qualifier, which
    causes the following build failure when building with the
    --enable-checking configure option (which adds -Werror to the CFLAGS):
    
      compile_et.c:170:7: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
        170 |     p = strrchr(whoami, '/');
            |       ^
      cc1: all warnings being treated as errors
    
    Change the strrchr() destination pointer from `char *` to `const char *`
    in the locations where the input string is a const char *.
    
    Add a new local variable in compile_et.c for the destination pointer,
    since the `char *` variable is reused in the affected function.
    
    Reviewed-on: https://gerrit.openafs.org/16750
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit a2887dbec96a3da5af5ff932032b936930b305f7)
    
    Change-Id: I0780580fcec7429ce10cf8cb2be6855d2f55de48
    Reviewed-on: https://gerrit.openafs.org/16751
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit befbc5ee733045f522dd74c7b60e46dbce7b5bff
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Fri Mar 6 12:25:13 2026 -0700

    Linux: Use __getname()/__putname() to alloc name
    
    The Linux 7.0 commit:
       'fs: hide names_cache behind runtime const machinery'
       (7ca83f8ebe867)
    make names_cachep a private symbol within namei support.  The commit:
       'struct filename: use names_cachep only for getname() and friends'
       (c3a3577cdb351)
    instructs users of names_cachep to simply allocate the memory via
    kmalloc.
    
    The Linux provided macros __getname() and __putname() perform the
    required memory allocation/free, switching from names_cachep to kmalloc
    in c3a3577cdb351.  These two macros have been available since at least
    2.6.18, so there is no need to add a specific autoconf test for them.
    
    Relocate afs_putname() to be ahead of afs_getname() and update to use
    __putname() to release the name.
    
    Update afs_getname() to use __getname() to obtain the storage for the
    name and call afs__putname() to release the name.
    
    Reviewed-on: https://gerrit.openafs.org/16699
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 2453ac257f8b6993cbb95bee077c332e01dc3551)
    
    Change-Id: Id4291990b50b2e5b86d55d4afa32d7d00f875491
    Reviewed-on: https://gerrit.openafs.org/16738
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 348b82ebb224061fe1dec3701e0c8e367254f207
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Tue Mar 10 14:24:54 2026 -0600

    Linux: Use set_default_d_op() to set dentry ops
    
    The Linux 6.17 commit:
        'new helper: set_default_d_op()' (05fb0e666495c)
    replaced the way that the default dentry_operations is set on a
    super_block. The s_d_op member was renamed to __s_d_op and a new helper
    function set_default_d_op() is now used to set the default
    dentry_operations.
    
    The OpenAFS commit 'linux: 2.6.38: New d_op handling' (08bb83d950) added
    an autoconf test for using the s_d_op member in the super_block struct.
    With the above Linux commit, the test for STRUCT_SUPER_BLOCK_HAS_S_D_OP
    fails, and the __s_d_op member in the super_block is not set during
    afs_fill_super(), but instead dp->d_op is set during various vfs
    operations. Doing so sets the dentry ops for the dentry, but does not
    set the flag DCACHE_OP_REVALIDATE on the dentry, and so Linux never
    calls our d_revalidate function, causing dentries to not get properly
    revalidated.
    
    To fix this, add a new autoconf test for set_default_d_op(), and use
    that function when available. Add a comment for the autoconf test for
    the super_block member s_d_op to note the change.  Add an additional
    build time check to ensure that we don't accidentally revert to the
    pre-2.6.38 behavior after Linux 2.6.38
    
    In afs_fill_super(), use set_default_d_op() to initialize the
    super_block with the afs_dentry_operations.
    
    The dentry->d_op member only needs to be updated when set_default_d_op()
    is not available and the super_block does not have the s_d_op member.
    
    Note: This commit fixes a reported problem with stale dentries that was
    discovered on a Linux 6.17 system.
    
    Reviewed-on: https://gerrit.openafs.org/16700
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    (cherry picked from commit a99b2ff4c04a9b1a4ba3ab5fac1b37bfd5d43568)
    
    Change-Id: Ic454c52ca88c82a9efa62a486ec05300a95c6cb0
    Reviewed-on: https://gerrit.openafs.org/16729
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 2a3548515dbb607f74ed4dbe1c13ec653d47ed64
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Mon Feb 23 14:42:40 2026 -0700

    Linux: implement aops->migrate_folio
    
    When the address_space_operations method writepages() was implemented in
    the openafs commit:
     'linux: convert aops->writepage to writepages' (b2c039541d66e)
    there should have been an implementation for the
    aops->migrate_folio method added as well (though it isn't mandatory).
    
    Linux provides a fallback if the filesystem has not implemented the
    migrate_folio method, however the fallback will issue a WARN_ONCE()
    kernel message:
    
    [ 1692.812667] afs_file_aops [libafs] does not implement migrate_folio
    [ 1692.812745] WARNING: CPU: 1 PID: 62 at mm/migrate.c:1053 move_to_new_folio+0x1a8/0x260
    [ 1692.812768] Modules linked in: libafs(PO)
     ... followed by registers and a stack trace ...
    
    Since openafs doesn't use folio->private, the Linux provided function
    migrate_folio() can be used.
    
    Move the preprocessor check that defines LINUX_WRITEPAGES_USES_FOLIOS
    towards the top of the file and add an include for linux/migrate.h.
    
    Initialize aops->migrate_folio element in the afs_file_aops structure
    to use migrate_folio().
    
    Note: the migrate_folio method is not documented as being mandatory for
    a filesystem to implement, however as noted above a kernel warning is
    issued if a filesystem doesn't implement the method.
    
    Looking a several of the other Linux filesystems, the commit messages
    associated with converting writepage -> writepages do mention having
    to add a aops->migrate_folio call.  See the Linux commits:
      'ceph: Remove ceph_writepage()' (19a2881104354) and
      'orangefs: Remove orangefs_writepage()' (506382dbbedc0)
    
    Most in-tree Linux filesystems use filemap_migrate_folio(), which we
    cannot use because it is GPL-only. migrate_folio() is almost identical
    to filemap_migrate_folio(); the only differences that are
    filemap_migrate_folio() handles the folio's folio->private (which we do
    not use), and migrate_folio() BUG()s if the folio's "writeback" flag is
    set (which should not happen; Linux waits for writeback to finish before
    migrating pages).
    
    Reviewed-on: https://gerrit.openafs.org/16689
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit daa3eef78addb187ced13355bff01a83f8d16f01)
    
    Change-Id: I53108b95e8eb695d951425e7b2d20e0b244736e7
    Reviewed-on: https://gerrit.openafs.org/16709
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 0bd855886c7b3b094634ac390a3389895fbc3ae0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Mon Feb 23 14:43:51 2026 -0700

    Linux: Pass 3rd parameter to filemap_alloc_folio()
    
    The Linux 6.19 commit:
        'mm/filemap: Add NUMA mempolicy support to filemap_alloc_folio()'
        (7f3779a3ac3e4)
    added a new parameter for future NUMA work.  Existing callers can pass a
    NULL for the new parameter.
    
    Add a new configure test to determine if filemap_alloc_folio uses 3
    parameters.
    
    Add a small wrapper for filemap_alloc_folio(), afs_filemap_alloc_folio()
    that uses the appropriate set of parameters for filemap_alloc_folio().
    Update afs_page_cache alloc() to use the wrapper.
    
    Reviewed-on: https://gerrit.openafs.org/16684
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 19451d31904be9bda1321f3a1ad3bdc2f31d3251)
    
    Change-Id: Idcb2096ecb84b7cb2d47744f67bc6da9f81d0f97
    Reviewed-on: https://gerrit.openafs.org/16708
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 444b4533f00657fe8c5835d45596cb011ad81f60
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Feb 5 11:14:10 2026 -0700

    Linux: Use sockaddr_unsized for socket->ops->bind
    
    The Linux 6.19 commits:
        'net: Add struct sockaddr_unsized for sockaddr of unknown length'
        (bf33247a90d3e)
    and
        'net: Convert proto_ops bind() callbacks to use sockaddr_unsized'
        (0e50474fa5148)
    updated the socket->ops->bind() method's signature to use a
    'struct sockaddr_unsized *' parameter instead of 'struct sockaddr *'.
    The only external change is that callers need to switch from casting
    to a (struct sockaddr *) to casting to a '(struct sockaddr_unsized *)'
    
    Add a new configure check to see if socket->ops->bind() requires a
    sockaddr_unsized parameter.
    
    The rx/LINUX rxk_NewSocket_Host is the only location where a call to
    socket->ops->bind() is made.  Add a C macro to handle the different
    casts depending on the results of the configure test.
    
    Notes:
    
    The only other socket->ops change was the connect() method and openafs
    does not use that method.
    
    For reference, see the Linux source for o2net_open_listening_sock() in
    fs/ocfs2/cluster/tcp.c, where the only change was in the cast used in
    the sock->ops->bind() call.
    
    Reviewed-on: https://gerrit.openafs.org/16683
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit f880d753f4fd866be99c732019b93861eb37769e)
    
    Change-Id: I99e27e59d629fef5168d7da69dcc57c080996496
    Reviewed-on: https://gerrit.openafs.org/16707
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 6a81d2779a8808e67a0a576171f14fb8c88a1da0
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Feb 5 11:13:09 2026 -0700

    Linux: Move afs_root()/_fill_super() in osi_vfsops
    
    Move afs_root() and afs_fill_super() functions ahead of the code that
    references them. For afs_fill_super(), this eliminates the need to have
    the preprocessor conditionals around the forward declaration of
    afs_fill_super().
    
    Move the afs_fs_type structure towards the bottom of the file, so that
    a data structure isn't intermixed with the functions.
    
    There are no functional changes in this commit.
    
    Reviewed-on: https://gerrit.openafs.org/16673
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit a369df49f842b6f269b8fa2710176a1e9ff92591)
    
    Change-Id: I80ae5a6264b6e2c2e83a408f20cab4571af8f280
    Reviewed-on: https://gerrit.openafs.org/16706
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit c1c2307bc74840af646570f2b84f265e125bf459
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri Feb 20 13:46:19 2026 -0600

    LINUX: Log warning on recursive folio writeback
    
    Since commit 4a587356a3 (linux-mmap-antirecursion-20081020) our page
    writeback functions have returned AOP_WRITEPAGE_ACTIVATE when detecting
    a recursive writeback request (afs_linux_writepage_sync() at the time,
    now afs_linux_prepare_writeback()). At the time, the recursion was noted
    as following this code path:
    
    afs_linux_writepage_sync -> afs_DoPartialWrite -> afs_StoreAllSegments
    -> osi_VM_StoreAllSegments -> filemap_fdatawrite -> [writeback]
    
    Since commit 5e0e1ea254 (linux-mmap-antirecursion-fix-20090512), the
    vcache was flaged as "in writeback" in afs_linux_writepage_sync()
    itself, rather than in osi_VM_StoreAllSegments(). But checks to avoid
    recursive calls were effectively in both afs_linux_writepage_sync()
    (which returned AOP_WRITEPAGE_ACTIVATE) and osi_VM_StoreAllSegments()
    (which just skipped the writeback).
    
    Later, in commit 95b857399d (Linux: mmap: Apply recursion check only to
    recursion cases), the check was restricted to catch only actual
    recursion, so writeback in different processes didn't trigger this.
    
    Since then, it's not clear if afs_linux_prepare_writeback() ever
    actually catches the recursion case and returns AOP_WRITEPAGE_ACTIVATE.
    With the current code, the above recursion code path now looks like
    this:
    
    afs_linux_end_writeback -> afs_linux_dopartialwrite ->
    afs_DoPartialWrite -> afs_StoreAllSegments -> osi_VM_StoreAllSegments ->
    filemap_fdatawrite -> [writeback]
    
    But now it shouldn't be possible for osi_VM_StoreAllSegments() to
    recurse into writeback, since avc->pagewriters will be non-empty when we
    call it from afs_linux_end_writeback(), and so osi_VM_StoreAllSegments()
    will return early. Handling the errors for this recursion is a strange,
    questionably-handled corner case in the page handling code for modern
    Linux with folios, so it would be nice to remove the
    AOP_WRITEPAGE_ACTIVATE code paths if they're not needed.
    
    However, it's hard to be sure there aren't other code paths that can
    also trigger similar recursion deadlocks. So for now, log a message with
    a stack trace when it happens, so we can try to do something about it if
    the log message is actually seen.
    
    Reviewed-on: https://gerrit.openafs.org/16697
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    (cherry picked from commit 1b3b3bc08e36ab5e0ee69e725d9834bfdeb4a4d8)
    
    Change-Id: I25d8518a70d1d51c37c9d6e5232bea327d437122
    Reviewed-on: https://gerrit.openafs.org/16705
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 4f53f2859ce2508ae5600a91e116af2eff5c9c99
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Feb 5 11:06:59 2026 -0700

    Linux: Avoid write_cache_pages() for ->writepages
    
    The Linux 6.18 commit:
        'mm: remove write_cache_pages' (7bebb41b96b5a)
    removed the Linux function write_cache_pages() without replacement.
    
    Within the OpenAFS kernel module, the function afs_linux_write_pages()
    implements the address_space_operations method ->writepages(). The
    afs_linux_write_pages() function calls write_cache_pages() and passes
    the callback function afs_linux_writefolio_cb() to handle the actual
    writing of individual folios.
    
    write_cache_pages() was a simple function that used writeback_iter() to
    iterate over dirty pages then called the provided callback function to
    perform the actual writing:
    
        aops->writepages (afs_linux_write_pages)
            -> write_cache_pages
               for folio in writeback_iter
               -> afs_linux_writefolio_cb(folio)
    
    With the removal of write_cache_pages(), the OpenAFS kernel module must
    iterate over the folios that need to be written. However,
    writeback_iter() is exported as GPL only and cannot be used by the
    OpenAFS kernel module.
    
    Without writeback_iter(), the function afs_linux_write_pages() will need
    to scan the mapping, in order to find the dirty folios directly.
    
    The aops->writepages() method is called to handle writing dirty folios
    from the page cache.  It is passed 2 parameters: a mapping and a
    writeback control, and is generally called in 2 situations:
      1 - To verify that the entire mapping is written to stable storage
          (typically after a sync, fsync, msync, unmount, etc) - WB_SYNC_ALL
      2 - During background pagecache cleaning - WB_SYNC_NONE
    
    In the first case, the entire specified range within the mapping needs
    to be scanned to locate and write out any dirty folios.  In the second
    case the mapping is being processed in chunks of folios and only a
    suggested number of pages are to be written out (the decision of exactly
    how many and which folios to be written is left to the individual file
    system).
    
    The writeback control determines if an entire range of folios within the
    mapping needs to be processed (WB_SYNC_ALL) or we can skip writeout for
    some pages (WB_SYNC_NONE).
    
    For the first case (WB_SYNC_ALL), the scan for dirty folios starts at
    the specified starting folio and continues up to and including the
    specified ending folio.
    
    For the second case (WB_SYNC_NONE), the scan starts at
    mapping->writeback_index and ends when the specified number of folios
    has been written, or we reach the end of the range.  If the end of the
    range is reached, we set the mapping->writeback_index to 0 before
    returning.
    
    The process for scanning and writing dirty folios within the mapping is
    mostly the same for both cases.
    
      Get a batch of folios tagged with "PAGECACHE_TAG_DIRTY" to look at (or
        in some cases, tag all dirty folios with PAGECACHE_TAG_TOWRITE, then
        look for PAGECACHE_TAG_TOWRITE pages).
      Look at each folio within the batch, if it's not within the provided
        mapping or it's not dirty, get the next folio from the current
        batch.
      Check the folio to see if it's currently already within a writeback.
        If so and WB_SYNC_ALL then wait for that writeback to finish.
        Otherwise the writepages call is part of a background cleanup and
        the folio can be skipped and a future aops->writepages call will
        handle it.
      Clear the dirty bit on the folio (and if it wasn't dirty skip
        additional processing on the folio).
      Call afs_linux_writefolio_cb() to actually handle the writing of the
        folio (this clears the PAGECACHE_TAG_TOWRITE/_DIRTY tag when we call
        folio_start_writeback()).  Mark the mapping if there was an error.
      Decrement the writeback control's number of pages to be written.
      If WB_SYNC_NONE, check to see if the writeback control request has
        been satisfied by writing out the requested number of pages.  If
        the writeback control is cyclic, update the mapping with the new
        starting point.  And exit.
      Continue processing the folios in batches.
    
    Update afs_linux_write_pages() with the new logic if the Linux kernel
    provides filemap_get_folios_tag() and doesn't have write_cache_pages()
    (LINUX_NEED_CUSTOM_WRITE_CACHE_PAGES). Remove the conditional around
    including pagevec.h to ensure the fbatch structure gets picked up.
    (pagevec.h was present in 2.6.12).
    
    Note:
    
    write_cache_pages() was introduced in 2.6.21 with the commit:
      'consolidate generic_writepages and mpage_writepages' (0ea9718016251)
    The callback used by write_cache_pages() was changed to use a folio in
    6.2 with the commit:
      'fs: convert writepage_t callback to pass a folio' (d585bdbeb79aa)
    filemap_get_folios_tag() was introduced with the 6.3 commit:
      'filemap: add filemap_get_folios_tag()' (247f9e1feef4)
    folio_batch_next() as introduced in 6.8 with the commit:
      'pagevec: add ability to iterate a queue' (535c5d9dadb32)
    
    Written in collaboration with adeason@sinenomine.net.
    
    Reviewed-on: https://gerrit.openafs.org/16648
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Tested-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    (cherry picked from commit 030378b1f430c36de90208dbca55056e05bbb2e3)
    
    Change-Id: Id3ccda56e28a3230842175073911bbea2be3ac97
    Reviewed-on: https://gerrit.openafs.org/16704
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 63a3503240c06187fa87514e5ea421cece483422
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Jan 8 16:43:19 2026 -0700

    Linux: Introduce LINUX_WRITE_CACHE_PAGES_USES_FOLIOS
    
    To clarify what is actually being tested, rename the autoconf test and
    variable:
        LINUX_WRITEPAGES_USES_FOLIOS => LINUX_WRITE_CACHE_PAGES_USES_FOLIOS
    
    Add a define in osi_vnodeops.c for LINUX_WRITEPAGES_USES_FOLIOS.  This
    allows future commits to add new cases that also define
    LINUX_WRITEPAGES_USES_FOLIOS.
    
    There are no functional changes in this commit.
    
    Reviewed-on: https://gerrit.openafs.org/16650
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit 5a2421f942ddee757093d9bba07d31c55610bc47)
    
    Change-Id: If404489eba41f4633de0cebe0d3c44336ae61032
    Reviewed-on: https://gerrit.openafs.org/16703
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit 11849e96820eca64d91742a8c521614e1e99d9fa
Author: Andrew Deason <adeason@sinenomine.net>
Date:   Fri Feb 20 11:57:49 2026 -0600

    LINUX: Re-dirty folio on writepages recursion
    
    Commit b2c039541d (linux: convert aops->writepage to writepages)
    introduced afs_linux_writefolio_cb(), and returned early when
    afs_linux_begin_writeback() detects recursion and returns
    AOP_WRITEPAGE_ACTIVATE. This follows similar existing logic in
    afs_linux_writepage(), but in this code path where write_cache_pages()
    calls afs_linux_writefolio_cb(), there is not much special handling for
    the AOP_WRITEPAGE_ACTIVATE return code (write_cache_pages() just unlocks
    the page).
    
    In afs_linux_writefolio_cb(), when we see AOP_WRITEPAGE_ACTIVATE and
    return, the page has not actually been written out and we never called
    folio_start_writeback() on the page. write_cache_pages() calls our
    afs_linux_writefolio_cb() after calling folio_clear_dirty_for_io(), so
    the dirty flag has been cleared on the page at this point. (Via:
    write_cache_pages -> writeback_iter -> writeback_get_folio ->
    folio_prepare_writeback -> folio_clear_dirty_for_io.) And
    folio_clear_dirty_for_io() clearly states in its comments that we are
    supposed to call either folio_start_writeback() or folio_mark_dirty()
    afterwards, in order to ensure coherence between the page's dirty flag
    and the page's dirty xarray tag.
    
    Also in this AOP_WRITEPAGE_ACTIVATE code path, we never folio_put() our
    extra folio_get()'d reference from earlier in this function, since we
    don't go through our 'goto done' destructor.
    
    So, to make sure the page is properly still marked as dirty in the
    AOP_WRITEPAGE_ACTIVATE case, call folio_mark_dirty() on it. Also release
    the extra reference with folio_put().
    
    Also return a normal success, instead of returning the special value
    AOP_WRITEPAGE_ACTIVATE. Our caller, write_cache_pages(), just unlocks
    the page and ignores the error, so returning this special value doesn't
    do anything special here, and just perpetuates a weird inconsistent
    calling convention.
    
    Reviewed-on: https://gerrit.openafs.org/16696
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    (cherry picked from commit 291a26a23bcf18b09f0c571d793273cc5e909123)
    
    Change-Id: I8d2890070f9f87bfb51454f35a1a35fdb2b4edff
    Reviewed-on: https://gerrit.openafs.org/16702
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>

commit c02a8f451b48766aa163e729abe40d145751b2dc
Author: Cheyenne Wills <cwills@sinenomine.net>
Date:   Thu Jan 8 09:38:31 2026 -0700

    Linux: Use get_tree_nodev
    
    The Linux 6.18 commit:
        'fs: Remove mount_nodev' (56ecfd9175b99)
    removed the mount_nodev() function that is used to handle the mount
    process.
    
    The OpenAFS Linux kernel module must use the newer mount APIs that were
    introduced with the Linux 5.0 commit:
        'introduce fs_context methods' (f3a09c92018a9)
    And the helper that was added with the Linux 5.2 commit:
        'convenience helper get_tree_nodev()' (2ac295d4f0c09)
    
    The newer mount API requires a filesystem to implement the methods
    defined within the fs_context_operations structure.  Of these methods,
    the only one needed for OpenAFS is the .get_tree() method which will
    simply return the result of a get_tree_nodev() call.
    
    Add an autoconf test for get_tree_nodev(), which is the replacement for
    mount_nodev() but using the newer mount APIs.
    
    Add a fs_context_operations structure that sets the get_tree method to
    point to afs_fc_get_tree(), which simply returns the value from
    get_tree_nodev().
    
    Add a function (afs_init_fs_context) to handle the file_system_type's
    init_fs_context method.  afs_init_fs_context() will update the
    fs_context to point to the afs_fs_context_ops.
    
    Update the afs_fs_type structure to initialize the init_fs_context and
    parameters members.
    
    Notes:
    The other methods within the fs_context_operations struct would only be
    applicable if OpenAFS was using private storage in the the fs_context,
    or needed to process command line parameters.
    
    The commit is retroactive back to Linux 5.2 since that is when the
    Linux kernel introduced get_tree_nodev().
    
    Reviewed-on: https://gerrit.openafs.org/16646
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
    Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    (cherry picked from commit 8d1ccc2b22a63053a0f15bd432033ca57a2110e7)
    
    Change-Id: I231a1d85cc3fdcfb1b4c06a3916e36dcd338d187
    Reviewed-on: https://gerrit.openafs.org/16701
    Tested-by: BuildBot <buildbot@rampaginggeek.com>
    Reviewed-by: Andrew Deason <adeason@sinenomine.net>
    Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
    Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
    Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
    Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
