1. Feb 11, 2022
  2. Feb 10, 2022
  3. Feb 09, 2022
    • Chuck Lever's avatar
      NFSD: Deprecate NFS_OFFSET_MAX · c306d737
      Chuck Lever authored
      
      
      NFS_OFFSET_MAX was introduced way back in Linux v2.3.y before there
      was a kernel-wide OFFSET_MAX value. As a clean up, replace the last
      few uses of it with its generic equivalent, and get rid of it.
      
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      c306d737
    • Chuck Lever's avatar
      NFSD: Fix offset type in I/O trace points · 6a4d333d
      Chuck Lever authored
      
      
      NFSv3 and NFSv4 use u64 offset values on the wire. Record these values
      verbatim without the implicit type case to loff_t.
      
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      6a4d333d
    • Chuck Lever's avatar
      NFSD: COMMIT operations must not return NFS?ERR_INVAL · 3f965021
      Chuck Lever authored
      
      
      Since, well, forever, the Linux NFS server's nfsd_commit() function
      has returned nfserr_inval when the passed-in byte range arguments
      were non-sensical.
      
      However, according to RFC 1813 section 3.3.21, NFSv3 COMMIT requests
      are permitted to return only the following non-zero status codes:
      
            NFS3ERR_IO
            NFS3ERR_STALE
            NFS3ERR_BADHANDLE
            NFS3ERR_SERVERFAULT
      
      NFS3ERR_INVAL is not included in that list. Likewise, NFS4ERR_INVAL
      is not listed in the COMMIT row of Table 6 in RFC 8881.
      
      RFC 7530 does permit COMMIT to return NFS4ERR_INVAL, but does not
      specify when it can or should be used.
      
      Instead of dropping or failing a COMMIT request in a byte range that
      is not supported, turn it into a valid request by treating one or
      both arguments as zero. Offset zero means start-of-file, count zero
      means until-end-of-file, so we only ever extend the commit range.
      NFS servers are always allowed to commit more and sooner than
      requested.
      
      The range check is no longer bounded by NFS_OFFSET_MAX, but rather
      by the value that is returned in the maxfilesize field of the NFSv3
      FSINFO procedure or the NFSv4 maxfilesize file attribute.
      
      Note that this change results in a new pynfs failure:
      
      CMT4     st_commit.testCommitOverflow                             : RUNNING
      CMT4     st_commit.testCommitOverflow                             : FAILURE
                 COMMIT with offset + count overflow should return
                 NFS4ERR_INVAL, instead got NFS4_OK
      
      IMO the test is not correct as written: RFC 8881 does not allow the
      COMMIT operation to return NFS4ERR_INVAL.
      
      Reported-by: default avatarDan Aloni <dan.aloni@vastdata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarBruce Fields <bfields@fieldses.org>
      3f965021
    • Chuck Lever's avatar
      NFSD: Clamp WRITE offsets · 6260d9a5
      Chuck Lever authored
      
      
      Ensure that a client cannot specify a WRITE range that falls in a
      byte range outside what the kernel's internal types (such as loff_t,
      which is signed) can represent. The kiocb iterators, invoked in
      nfsd_vfs_write(), should properly limit write operations to within
      the underlying file system's s_maxbytes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      6260d9a5
    • Chuck Lever's avatar
      NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes · a648fdeb
      Chuck Lever authored
      
      
      iattr::ia_size is a loff_t, so these NFSv3 procedures must be
      careful to deal with incoming client size values that are larger
      than s64_max without corrupting the value.
      
      Silently capping the value results in storing a different value
      than the client passed in which is unexpected behavior, so remove
      the min_t() check in decode_sattr3().
      
      Note that RFC 1813 permits only the WRITE procedure to return
      NFS3ERR_FBIG. We believe that NFSv3 reference implementations
      also return NFS3ERR_FBIG when ia_size is too large.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      a648fdeb
    • Chuck Lever's avatar
      NFSD: Fix ia_size underflow · e6faac3f
      Chuck Lever authored
      
      
      iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
      NFSv4 both define file size as an unsigned 64-bit type. Thus there
      is a range of valid file size values an NFS client can send that is
      already larger than Linux can handle.
      
      Currently decode_fattr4() dumps a full u64 value into ia_size. If
      that value happens to be larger than S64_MAX, then ia_size
      underflows. I'm about to fix up the NFSv3 behavior as well, so let's
      catch the underflow in the common code path: nfsd_setattr().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      e6faac3f
    • Chuck Lever's avatar
      NFSD: Fix the behavior of READ near OFFSET_MAX · 0cb4d23a
      Chuck Lever authored
      Dan Aloni reports:
      > Due to commit 8cfb9015
      
       ("NFS: Always provide aligned buffers to
      > the RPC read layers") on the client, a read of 0xfff is aligned up
      > to server rsize of 0x1000.
      >
      > As a result, in a test where the server has a file of size
      > 0x7fffffffffffffff, and the client tries to read from the offset
      > 0x7ffffffffffff000, the read causes loff_t overflow in the server
      > and it returns an NFS code of EINVAL to the client. The client as
      > a result indefinitely retries the request.
      
      The Linux NFS client does not handle NFS?ERR_INVAL, even though all
      NFS specifications permit servers to return that status code for a
      READ.
      
      Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
      and return a short result. Set the EOF flag in the result to prevent
      the client from retrying the READ request. This behavior appears to
      be consistent with Solaris NFS servers.
      
      Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
      must be converted to loff_t internally before use -- an implicit
      type cast is not adequate for this purpose. Otherwise VFS checks
      against sb->s_maxbytes do not work properly.
      
      Reported-by: default avatarDan Aloni <dan.aloni@vastdata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      0cb4d23a
    • H. Nikolaus Schaller's avatar
      MIPS: DTS: CI20: fix how ddc power is enabled · d9565bf4
      H. Nikolaus Schaller authored
      Originally we proposed a new hdmi-5v-supply regulator reference
      for CI20 device tree but that was superseded by a better idea to use
      the already defined "ddc-en-gpios" property of the "hdmi-connector".
      
      Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
      been applied to v5.17-rc1, we add this on top.
      
      Fixes: ae1b8d2c
      
       ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
      Signed-off-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Reviewed-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      d9565bf4
    • Linus Torvalds's avatar
      Merge tag 'nfs-for-5.17-2' of git://git.linux-nfs.org/projects/anna/linux-nfs · e6251ab4
      Linus Torvalds authored
      Pull NFS client fixes from Anna Schumaker:
       "Stable Fixes:
      
         - Fix initialization of nfs_client cl_flags
      
        Other Fixes:
      
         - Fix performance issues with uncached readdir calls
      
         - Fix potential pointer dereferences in rpcrdma_ep_create
      
         - Fix nfs4_proc_get_locations() kernel-doc comment
      
         - Fix locking during sunrpc sysfs reads
      
         - Update my email address in the MAINTAINERS file to my new
           kernel.org email"
      
      * tag 'nfs-for-5.17-2' of git://git.linux-nfs.org/projects/anna/linux-nfs:
        SUNRPC: lock against ->sock changing during sysfs read
        MAINTAINERS: Update my email address
        NFS: Fix nfs4_proc_get_locations() kernel-doc comment
        xprtrdma: fix pointer derefs in error cases of rpcrdma_ep_create
        NFS: Fix initialisation of nfs_client cl_flags field
        NFS: Avoid duplicate uncached readdir calls on eof
        NFS: Don't skip directory entries when doing uncached readdir
        NFS: Don't overfill uncached readdir pages
      e6251ab4
  4. Feb 08, 2022
  5. Feb 07, 2022
    • Damien Le Moal's avatar
      ata: libata-core: Fix ata_dev_config_cpr() · fda17afc
      Damien Le Moal authored
      The concurrent positioning ranges log page 47h is a general purpose log
      page and not a subpage of the indentify device log. Using
      ata_identify_page_supported() to test for concurrent positioning ranges
      support is thus wrong. ata_log_supported() must be used.
      
      Furthermore, unlike other advanced ATA features (e.g. NCQ priority),
      accesses to the concurrent positioning ranges log page are not gated by
      a feature bit from the device IDENTIFY data. Since many older drives
      react badly to the READ LOG EXT and/or READ LOG DMA EXT commands isued
      to read device log pages, avoid problems with older drives by limiting
      the concurrent positioning ranges support detection to drives
      implementing at least the ACS-4 ATA standard (major version 11). This
      additional condition effectively turns ata_dev_config_cpr() into a nop
      for older drives, avoiding problems in the field.
      
      Fixes: fe22e1c2 ("libata: support concurrent positioning ranges log")
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215519
      
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Tested-by: default avatarAbderraouf Adjal <adjal.arf@gmail.com>
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      fda17afc
    • Linus Torvalds's avatar
      Linux 5.17-rc3 · dfd42fac
      Linus Torvalds authored
      dfd42fac