1. 01 Dec, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Do not try to cache a reply for NFSERR_BADSLOT · 33d0be8a
      Rick Macklem authored
      When nfsrv_checksequence() replies NFSERR_BADSLOT,
      the value of nd_slotid is not valid.  As such, the
      reply cannot be cached in the session.
      Do not set ND_HASSEQUENCE for this case.
      
      Reported by:	rtm@lcs.mit.edu
      Tested by:	rtm@lcs.mit.edu
      PR:	260076
      MFC after:	2 weeks
      33d0be8a
  2. 28 Nov, 2021 1 commit
    • Rick Macklem's avatar
      nfs: Quiet a few "unused" warnings · 638b90a1
      Rick Macklem authored
      For most of these warnings, the variable is loaded
      with data parsed out of an RPC messages.  In case
      the data is useful in the future, I just marked
      these with __unused.
      638b90a1
  3. 26 Nov, 2021 2 commits
    • Rick Macklem's avatar
      nfsd: Sanity check the len argument for ListXattr · 5b430a13
      Rick Macklem authored
      The check for the original len being >= retlen needs to
      be done before the "if (nd->nd_repstat == 0)" code, so
      that it can be reported as too small.
      
      Reported by:	rtm@lcs.mit.edu
      Tested by:	rtm@lcs.mit.edu
      PR:	260046
      MFC after:	2 weeks
      5b430a13
    • Rick Macklem's avatar
      nfsd: Add checks for layout errors in LayoutReturn · bdd57cbb
      Rick Macklem authored
      For a LayoutReturn when using the Flexible File Layout,
      error reports may be provided in the request.
      Sanity check the size of these error reports and
      check that they exist before calling nfsrv_flexlayouterr().
      
      Reported by:	rtm@lcs.mit.edu
      Tested by:	rtm@lcs.mit.edu
      PR:	260012
      MFC after:	2 weeks
      bdd57cbb
  4. 08 Nov, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Fix the NFSv4.2 pNFS MDS server for NFSERR_NOSPC via LayoutError · f8dc0630
      Rick Macklem authored
      If a pNFS server's DS runs out of disk space, it replies
      NFSERR_NOSPC to the client doing writing.  For the Linux
      client, it then sends a LayoutError RPC to the MDS server to
      tell it about the error and keeps retrying, doing repeated
      LayoutGets to the MDS and Write RPCs to the DS.  The Linux client is
      "stuck" until disk space on the DS is free'd up unless
      a subsequent LayoutGet request is sent a NFSERR_NOSPC
      reply.
      The looping problem still occurs for NFSv4.1 mounts, but no
      fix for this is known at this time.
      
      This patch changes the pNFS MDS server to reply to LayoutGet
      operations with NFSERR_NOSPC once a LayoutError reports the
      problem, until the DS has available space.  This keeps the Linux
      NFSv4.2 from looping.
      
      Found during recent testing because of issues w.r.t. a DS
      being out of space found during a recent IEFT NFSv4 working
      group testing event.
      
      MFC after:	2 weeks
      f8dc0630
  5. 07 Nov, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Fix the NFSv4 pNFS MDS server for DS NFSERR_NOSPC · a7e014ee
      Rick Macklem authored
      If a pNFS server's DS runs out of disk space, it replies
      NFSERR_NOSPC to the client doing writing.  For the Linux
      client, it then sends a LayoutError RPC to the server to
      tell it about the error and keeps retrying, doing repeated
      LayoutGet and Write RPCs to the DS.  The Linux client is
      "stuck" until disk space on the DS is free'd up.
      For a mirrored server configuration, the first mirror that
      ran out of space was taken offline.  This does not make
      much sense, since the other mirror(s) will run out of space
      soon and the fix is a manual cleanup up disk space.
      
      This patch changes the pNFS server to not disable a mirror
      for the mirrored case when this occurs.
      
      Further work is needed, since the Linux client expects the
      MDS to reply NFSERR_NOSPC to LayoutGets once the DS is out
      of space.  Without this further change, the above mentioned
      looping occurs.
      
      Found during a recent IEFT NFSv4 working group testing event.
      
      MFC after:	2 weeks
      a7e014ee
  6. 11 Oct, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Disable the NFSv4.2 Allocate operation by default · dfe887b7
      Rick Macklem authored
      Some exported file systems, such as ZFS ones, cannot do VOP_ALLOCATE().
      Since an NFSv4.2 server must either support the Allocate operation for
      all file systems or not support it at all, define a sysctl called
      vfs.nfsd.enable_v42allocate to enable the Allocate operation.
      This sysctl is false by default and can only be set true if all
      exported file systems (or all DSs for a pNFS server) can perform
      VOP_ALLOCATE().
      
      Unfortunately, there is no way to know if a ZFS file system will
      be exported once the nfsd is operational, even if there are none
      exported when the nfsd is started up, so enabling Allocate must
      be done manually for a server configuration.
      
      This problem was detected during a recent NFSv4 interoperability
      testing event held by the IETF working group.
      
      MFC after:	2 weeks
      dfe887b7
  7. 02 Oct, 2021 1 commit
  8. 14 Sep, 2021 1 commit
    • Alexander Motin's avatar
      Allow setting NFS server scope and owner. · 272c4a4d
      Alexander Motin authored
      By default NFS server reports as scope and owner major the host UUID
      value and zero for owner minor.  It works good in case of standalone
      server.  But in case of CARP-based HA cluster failover the values
      should remain persistent, otherwise some clients like VMware ESXi
      get confused by the change and fail to reconnect automatically.
      
      The patch makes server scope, major owner and minor owner values
      configurable via sysctls.  If not set (by default) the host UUID
      value is still used.
      
      Reviewed by:	rmacklem
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D31952
      272c4a4d
  9. 09 Sep, 2021 1 commit
  10. 08 Sep, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Use the COPY_FILE_RANGE_TIMEO1SEC flag · 103b2075
      Rick Macklem authored
      Although it is not specified in the RFCs, the concept that
      the NFSv4 server should reply to an RPC request within a
      reasonable time is accepted practice within the NFSv4 community.
      
      Without this patch, the NFSv4.2 server attempts to reply to
      a Copy operation within 1 second by limiting the copy to
      vfs.nfs.maxcopyrange bytes (default 10Mbytes). This is crude at
      best, given the large variation in I/O subsystem performance.
      
      This patch uses the COPY_FILE_RANGE_TIMEO1SEC flag added by
      commit c5128c48 to limit the reply time for a Copy
      operation to approximately 1 second.
      
      MFC after:	2 weeks
      103b2075
  11. 27 Aug, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Add support for the NFSv4.2 Deallocate operation · bb958dcf
      Rick Macklem authored
      The recently added VOP_DEALLOCATE(9) VOP call allows
      implementation of the Deallocate NFSv4.2 operation.
      
      Since the Deallocate operation is a single succeed/fail
      operation, the call to VOP_DEALLOCATE(9) loops so long
      as progress is being made.  It calls maybe_yield()
      between loop iterations to allow other processes
      to preempt it.
      
      Where RFC 7862 underspecifies behaviour, the code
      is written to be Linux NFSv4.2 server compatible.
      
      Reviewed by:	khng
      Differential Revision:	https://reviews.freebsd.org/D31624
      bb958dcf
  12. 12 Aug, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Fix sanity check for NFSv4.2 Allocate operations · 06afb53b
      Rick Macklem authored
      The NFSv4.2 Allocate operation sanity checks the aa_offset
      and aa_length arguments.  Since they are assigned to variables
      of type off_t (signed) it was possible for them to be negative.
      It was also possible for aa_offset+aa_length to exceed OFF_MAX
      when stored in lo_end, which is uint64_t.
      
      This patch adds checks for these cases to the sanity check.
      
      Reviewed by:	kib
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D31511
      06afb53b
  13. 16 Jul, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Add sysctl to set maximum I/O size up to 1Mbyte · ee29e6f3
      Rick Macklem authored
      Since MAXPHYS now allows the FreeBSD NFS client
      to do 1Mbyte I/O operations, add a sysctl called vfs.nfsd.srvmaxio
      so that the maximum NFS server I/O size can be set up to 1Mbyte.
      The Linux NFS client can also do 1Mbyte I/O operations.
      
      The default of 128Kbytes for the maximum I/O size has
      not been changed for two reasons:
      - kern.ipc.maxsockbuf must be increased to support 1Mbyte I/O
      - The limited benchmarking I can do actually shows a drop in I/O rate
        when the I/O size is above 256Kbytes.
      However, daveb@spectralogic.com reports seeing an increase
      in I/O rate for the 1Mbyte I/O size vs 128Kbytes using a Linux client.
      
      Reviewed by:	asomers
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D30826
      ee29e6f3
  14. 05 Jun, 2021 2 commits
    • Rick Macklem's avatar
      nfsd: Fix when NFSERR_WRONGSEC may be replied to NFSv4 clients · a5df139e
      Rick Macklem authored
      Commit d224f05f pre-parsed the next operation number for
      the put file handle operations.  This patch uses this next
      operation number, plus the type of the file handle being set by
      the put file handle operation, to implement the rules in RFC5661
      Sec. 2.6 with respect to replying NFSERR_WRONGSEC.
      
      This patch also adds a check to see if NFSERR_WRONGSEC should be
      replied when about to perform Lookup, Lookupp or Open with a file
      name component, so that the NFSERR_WRONGSEC reply is done for
      these operations, as required by RFC5661 Sec. 2.6.
      
      This patch does not have any practical effect for the FreeBSD NFSv4
      client and I believe that the same is true for the Linux client,
      since NFSERR_WRONGSEC is considered a fatal error at this time.
      
      MFC after:	2 weeks
      a5df139e
    • Rick Macklem's avatar
      nfsd: Fix NFSv4.1/4.2 Secinfo_no_name when security flavors empty · 56e9d8e3
      Rick Macklem authored
      Commit 947bd247 added support for the Secinfo_no_name operation.
      When a non-exported file system is being traversed, the list of
      security flavors is empty.  It turns out that the Linux client
      mount attempt fails when the security flavors list in the
      Secinfo_no_name reply is empty.
      
      This patch modifies Secinfo/Secinfo_no_name so that it replies
      with all four security flavors when the list is empty.
      This fixes Linux NFSv4.1/4.2 mounts when the file system at
      the NFSv4 root (as specified on a V4: exports(5) line) is
      not exported.
      
      MFC after:	2 weeks
      56e9d8e3
  15. 02 Jun, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Fix the failure return for non-fh NFSv4 operations · 984c71f9
      Rick Macklem authored
      Without this patch, nfsd_checkrootexp() returns failure
      and then the NFSv4 operation would reply NFSERR_WRONGSEC.
      RFC5661 Sec. 2.6 only allows a few NFSv4 operations, none
      of which call nfsv4_checktootexp(), to return NFSERR_WRONGSEC.
      This patch modifies nfsd_checkrootexp() to return the
      error instead of a boolean and sets the returned error to an RPC
      layer AUTH_ERR, as discussed on nfsv4@ietf.org.
      The patch also fixes nfsd_errmap() so that the pseudo
      error NFSERR_AUTHERR is handled correctly such that an RPC layer
      AUTH_ERR is replied to the NFSv4 client.
      
      The two new "enum auth_stat" values have not yet been assigned
      by IANA, but are the expected next two values.
      
      The effect on extant NFSv4 clients of this change appears
      limited to reporting a different failure error when a
      mount that does not use adequate security is attempted.
      
      MFC after:	2 weeks
      984c71f9
  16. 01 Jun, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Delete extraneous NFSv4 root checks · 1d4afcac
      Rick Macklem authored
      There are several NFSv4.1/4.2 server operation functions which
      have unneeded checks for the NFSv4 root being set up.
      The checks are not needed because the operations always follow
      a Sequence operation, which performs the check.
      
      This patch deletes these checks, simplifying the code so
      that a future patch that fixes the checks to conform with
      RFC5661 Sec. 2.6 will be less extension.
      
      MFC after:	2 weeks
      1d4afcac
  17. 31 May, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Add support for the NFSv4.1/4.2 Secinfo_no_name operation · 947bd247
      Rick Macklem authored
      The Linux client is now attempting to use the Secinfo_no_name
      operation for NFSv4.1/4.2 mounts.  Although it does not seem to
      mind the NFSERR_NOTSUPP reply, adding support for it seems
      reasonable.
      
      I also noticed that "savflag" needed to be 64bits in
      nfsrvd_secinfo() since nd_flag in now 64bits, so I changed
      the declaration of it there.  I also added code to set "vp" NULL
      after performing Secinfo/Secinfo_no_name, since these
      operations consume the current FH, which is represented
      by "vp" in nfsrvd_compound().
      
      Fixing when the server replies NFSERR_WRONGSEC so that
      it conforms to RFC5661 Sec. 2.6 still needs to be done
      in a future commit.
      
      MFC after:	2 weeks
      947bd247
  18. 21 May, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Add support for CLAIM_DELEG_PREV_FH to the NFSv4.1/4.2 Open · d80a903a
      Rick Macklem authored
      Commit b3d4c70d added support for CLAIM_DELEG_CUR_FH to Open.
      While doing this, I noticed that CLAIM_DELEG_PREV_FH support
      could be added the same way.  Although I am not aware of any extant
      NFSv4.1/4.2 client that uses this claim type, it seems prudent to add
      support for this variant of Open to the NFSv4.1/4.2 server.
      
      This patch does not affect mounts from extant NFSv4.1/4.2 clients,
      as far as I know.
      
      MFC after:	2 weeks
      d80a903a
  19. 18 May, 2021 1 commit
    • Rick Macklem's avatar
      nfsd: Add support for CLAIM_DELEG_CUR_FH to the NFSv4.1/4.2 Open · b3d4c70d
      Rick Macklem authored
      The Linux NFSv4.1/4.2 client now uses the CLAIM_DELEG_CUR_FH
      variant of the Open operation when delegations are recalled and
      the client has a local open of the file.  This patch adds
      support for this variant of Open to the NFSv4.1/4.2 server.
      
      This patch only affects mounts from Linux clients when delegations
      are enabled on the server.
      
      MFC after:	2 weeks
      b3d4c70d
  20. 08 May, 2021 1 commit
    • Rick Macklem's avatar
      nfscl: Add support for va_birthtime to NFSv4 · dd02d9d6
      Rick Macklem authored
      There is a NFSv4 file attribute called TimeCreate
      that can be used for va_birthtime.
      r362175 added some support for use of TimeCreate.
      This patch completes support of va_birthtime by adding
      support for setting this attribute to the server.
      It also eanbles the client to
      acquire and set the attribute for a NFSv4
      server that supports the attribute.
      
      Reviewed by:	markj
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D30156
      dd02d9d6
  21. 01 Sep, 2020 1 commit
  22. 31 Aug, 2020 1 commit
  23. 27 Aug, 2020 1 commit
    • Rick Macklem's avatar
      Add flags to enable NFS over TLS to the NFS client and server. · 6e4b6ff8
      Rick Macklem authored
      An Internet Draft titled "Towards Remote Procedure Call Encryption By Default"
      (soon to be an RFC I think) describes how Sun RPC is to use TLS with NFS
      as a specific application case.
      Various commits prepared the NFS code to use KERN_TLS, mainly enabling use
      of ext_pgs mbufs for large RPC messages.
      r364475 added TLS support to the kernel RPC.
      
      This commit (which is the final one for kernel changes required to do
      NFS over TLS) adds support for three export flags:
      MNT_EXTLS - Requires a TLS connection.
      MNT_EXTLSCERT - Requires a TLS connection where the client presents a valid
                  X.509 certificate during TLS handshake.
      MNT_EXTLSCERTUSER - Requires a TLS connection where the client presents a
                  valid X.509 certificate with "user@domain" in the otherName
                  field of the SubjectAltName during TLS handshake.
      Without these export options, clients are permitted, but not required, to
      use TLS.
      
      For the client, a new nmount(2) option called "tls" makes the client do
      a STARTTLS Null RPC and TLS handshake for all TCP connections used for the
      mount. The CLSET_TLS client control option is used to indicate to the kernel RPC
      that this should be done.
      
      Unless the above export flags or "tls" option is used, semantics should
      not change for the NFS client nor server.
      
      For NFS over TLS to work, the userspace daemons rpctlscd(8) { for client }
      or rpctlssd(8) daemon { for server } must be running.
      6e4b6ff8
  24. 31 Jul, 2020 1 commit
    • Rick Macklem's avatar
      Add optional support for ext_pgs mbufs to the NFS server's read, readlink · cb889ce6
      Rick Macklem authored
      and getxattr operations.
      
      This patch optionally enables generation of read, readlink and getxattr replies
      in ext_pgs mbufs.  Since neither of ND_EXTPG or ND_TLS are currently ever set,
      there is no change in semantics at this time.
      It also corrects the message in a couple of panic()s that should never occur.
      
      This is another in the series of commits that add support to the NFS client
      and server for building RPC messages in ext_pgs mbufs with anonymous pages.
      This is useful so that the entire mbuf list does not need to be
      copied before calling sosend() when NFS over TLS is enabled.
      
      Use of ext_pgs mbufs will not be enabled until the kernel RPC is updated
      to handle TLS.
      cb889ce6
  25. 26 Jul, 2020 1 commit
    • Rick Macklem's avatar
      Add support for ext_pgs mbufs to nfsrv_adj(). · 18a48314
      Rick Macklem authored
      This patch uses a slightly different algorithm for nfsrv_adj()
      since ext_pgs mbuf lists are not permitted to have m_len == 0 mbufs.
      As such, the code now frees mbufs after the adjustment in the list instead
      of setting their m_len field to 0.
      Since mbuf(s) may be trimmed off the tail of the list, the function now
      returns a pointer to the last mbuf in the list.  This saves the caller
      from needing to use m_last() to find the last mbuf.
      It also implies that it might return a nul list, which required a check for
      that in nfsrvd_readlink().
      
      This is another in the series of commits that add support to the NFS client
      and server for building RPC messages in ext_pgs mbufs with anonymous pages.
      This is useful so that the entire mbuf list does not need to be
      copied before calling sosend() when NFS over TLS is enabled.
      
      Use of ext_pgs mbufs will not be enabled until the kernel RPC is updated
      to handle TLS.
      18a48314
  26. 17 Jun, 2020 1 commit
  27. 12 May, 2020 1 commit
  28. 08 May, 2020 1 commit
  29. 17 Apr, 2020 1 commit
    • Rick Macklem's avatar
      Replace all instances of the typedef mbuf_t with "struct mbuf *". · ae070589
      Rick Macklem authored
      The typedef mbuf_t was used for the Mac OS/X port of the code long ago.
      Since this port is no longer used and the use of mbuf_t obscures what
      the code does (and is not consistent with style(9)), it is no longer needed.
      This patch replaces all instances of mbuf_t with "struct mbuf *", so that
      it is no longer used.
      
      This patch should not result in any semantic change.
      ae070589
  30. 15 Apr, 2020 1 commit
    • Rick Macklem's avatar
      Fix the NFSv4.2 extended attribute support for remove extended attrbute. · 0bda1ddd
      Rick Macklem authored
      I missed the "atomic" field of the RemoveExtendedAttribute operation's
      reply when I implemented it. It worked between FreeBSD client and server,
      since it was missed for both, but it did not conform to RFC 8276.
      This patch adds the field for both client and server.
      
      Thanks go to Frank for doing interoperability testing of the extended
      attribute support against patches for Linux.
      
      Submitted by:	Frank van der Linden <fllinden@amazon.com>
      Reported by:	Frank van der Linden <fllinden@amazon.com>
      0bda1ddd
  31. 14 Apr, 2020 1 commit
    • Rick Macklem's avatar
      Fix the NFSv2 extended attribute support to handle 0 length attributes. · fb8ed4c5
      Rick Macklem authored
      I did not realize that zero length attributes are allowed, but they are.
      This patch fixes the NFSv4.2 client and server to handle zero length
      extended attributes correctly.
      
      Submitted by:	Frank van der Linden <fllinden@amazon.com> (earlier version)
      Reported by:	Frank van der Linden <fllinder@amazon.com>
      fb8ed4c5
  32. 11 Apr, 2020 1 commit
    • Rick Macklem's avatar
      Replace mbuf macros with the code they would generate in the NFS code. · 9f6624d3
      Rick Macklem authored
      When the code was ported to Mac OS/X, mbuf handling functions were
      converted to using the Mac OS/X accessor functions. For FreeBSD, they
      are a simple set of macros in sys/fs/nfs/nfskpiport.h.
      Since porting to Mac OS/X is no longer a consideration, replacement of
      these macros with the code generated by them makes the code more
      readable.
      When support for external page mbufs is added as needed by the KERN_TLS,
      the patch becomes simpler if done without the macros.
      
      This patch should not result in any semantic change.
      9f6624d3
  33. 08 Apr, 2020 1 commit
    • Rick Macklem's avatar
      Fix an interoperability issue w.r.t. the Linux client and the NFSv4 server. · b0b7d978
      Rick Macklem authored
      Luoqi Chen reported a problem on freebsd-fs@ where a Linux NFSv4 client
      was able to open and write to a file when the file's permissions were
      not set to allow the owner write access.
      
      Since NFS servers check file permissions on every write RPC, it is standard
      practice to allow the owner of the file to do writes, regardless of
      file permissions. This provides POSIX like behaviour, since POSIX only
      checks permissions upon open(2).
      The traditional way NFS clients handle this is to check access via the
      Access operation/RPC and use that to determine if an open(2) on the
      client is allowed.
      
      It appears that, for NFSv4, the Linux client expects the NFSv4 Open (not a
      POSIX open) operation to fail with NFSERR_ACCES if the file is not being
      created and file permissions do not allow owner access, unlike NFSv3.
      Since both the Linux and OpenSolaris NFSv4 servers seem to exhibit this
      behaviour, this patch changes the FreeBSD NFSv4 server to do the same.
      A sysctl called vfs.nfsd.v4openaccess can be set to 0 to return the
      NFSv4 server to its previous behaviour.
      
      Since both the Linux and FreeBSD NFSv4 clients seem to exhibit correct
      behaviour with the access check for file owner in Open enabled, it is enabled
      by default.
      
      Reported by:	luoqi.chen@gmail.com
      MFC after:	2 weeks
      b0b7d978
  34. 03 Jan, 2020 1 commit
  35. 13 Dec, 2019 1 commit
  36. 12 Dec, 2019 1 commit
    • Rick Macklem's avatar
      Add support for NFSv4.2 to the NFS client and server. · c057a378
      Rick Macklem authored
      This patch adds support for NFSv4.2 (RFC-7862) and Extended Attributes
      (RFC-8276) to the NFS client and server.
      NFSv4.2 is comprised of several optional features that can be supported
      in addition to NFSv4.1. This patch adds the following optional features:
         - posix_fadvise(POSIX_FADV_WILLNEED/POSIX_FADV_DONTNEED)
         - posix_fallocate()
         - intra server file range copying via the copy_file_range(2) syscall
           --> Avoiding data tranfer over the wire to/from the NFS client.
         - lseek(SEEK_DATA/SEEK_HOLE)
         - Extended attribute syscalls for "user" namespace attributes as defined
           by RFC-8276.
      
      Although this patch is fairly large, it should not affect support for
      the other versions of NFS. However it does add two new sysctls that allow
      a sysadmin to limit which minor versions of NFSv4 a server supports, allowing
      a sysadmin to disable NFSv4.2.
      
      Unfortunately, when the NFS stats structure was last revised, it was assumed
      that there would be no additional operations added beyond what was
      specified in RFC-7862. However RFC-8276 did add additional operations,
      forcing the NFS stats structure to revised again. It now has extra unused
      entries in all arrays, so that future extensions to NFSv4.2 can be
      accomodated without revising this structure again.
      
      A future commit will update nfsstat(1) to report counts for the new NFSv4.2
      specific operations/procedures.
      
      This patch affects the internal interface between the nfscommon, nfscl and
      nfsd modules and, as such, they all must be upgraded simultaneously.
      I will do a version bump (although arguably not needed), due to this.
      
      This code has survived a "make universe" but has not been built with a
      recent GCC. If you encounter build problems, please email me.
      
      Relnotes:	yes
      c057a378
  37. 08 Dec, 2019 1 commit
    • Mateusz Guzik's avatar
      vfs: introduce v_irflag and make v_type smaller · abd80ddb
      Mateusz Guzik authored
      The current vnode layout is not smp-friendly by having frequently read data
      avoidably sharing cachelines with very frequently modified fields. In
      particular v_iflag inspected for VI_DOOMED can be found in the same line with
      v_usecount. Instead make it available in the same cacheline as the v_op, v_data
      and v_type which all get read all the time.
      
      v_type is avoidably 4 bytes while the necessary data will easily fit in 1.
      Shrinking it frees up 3 bytes, 2 of which get used here to introduce a new
      flag field with a new value: VIRF_DOOMED.
      
      Reviewed by:	kib, jeff
      Differential Revision:	https://reviews.freebsd.org/D22715
      abd80ddb
  38. 19 Apr, 2019 1 commit
    • Rick Macklem's avatar
      Add support for the ModeSetMasked attribute to the NFSv4.1 server. · b4372164
      Rick Macklem authored
      I do not know of an extant NFSv4.1 client that currently does a Setattr
      operation for the ModeSetMasked, but it has been discussed on the linux-nfs
      mailing list.
      This patch adds support for doing a Setattr of ModeSetMasked, so that it
      will work for any future NFSv4.1 client that chooses to do so.
      Tested via a hacked FreeBSD NFSv4.1 client.
      
      MFC after:	2 weeks
      b4372164