1. 08 11月, 2017 1 次提交
    • A
      nfds: avoid gettimeofday for nfssvc_boot time · 256a89fa
      Arnd Bergmann 提交于
      do_gettimeofday() is deprecated and we should generally use time64_t
      based functions instead.
      
      In case of nfsd, all three users of nfssvc_boot only use the initial
      time as a unique token, and are not affected by it overflowing, so they
      are not affected by the y2038 overflow.
      
      This converts the structure to timespec64 anyway and adds comments
      to all uses, to document that we have thought about it and avoid
      having to look at it again.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      256a89fa
  2. 06 10月, 2017 1 次提交
    • E
      nfsd4: define nfsd4_secinfo_no_name_release() · ec572b9e
      Eryu Guan 提交于
      Commit 34b1744c ("nfsd4: define ->op_release for compound ops")
      defined a couple ->op_release functions and run them if necessary.
      
      But there's a problem with that is that it reused
      nfsd4_secinfo_release() as the op_release of OP_SECINFO_NO_NAME, and
      caused a leak on struct nfsd4_secinfo_no_name in
      nfsd4_encode_secinfo_no_name(), because there's no .si_exp field in
      struct nfsd4_secinfo_no_name.
      
      I found this because I was unable to umount an ext4 partition after
      exporting it via NFS & run fsstress on the nfs mount. A simplified
      reproducer would be:
      
       # mount a local-fs device at /mnt/test, and export it via NFS with
       # fsid=0 export option (this is required)
       mount /dev/sda5 /mnt/test
       echo "/mnt/test *(rw,no_root_squash,fsid=0)" >> /etc/exports
       service nfs restart
      
       # locally mount the nfs export with all default, note that I have
       # nfsv4.1 configured as the default nfs version, because of the
       # fsid export option, v4 mount would fail and fall back to v3
       mount localhost:/mnt/test /mnt/nfs
      
       # try to umount the underlying device, but got EBUSY
       umount /mnt/nfs
       service nfs stop
       umount /mnt/test <=== EBUSY here
      
      Fixed it by defining a separate nfsd4_secinfo_no_name_release()
      function as the op_release method of OP_SECINFO_NO_NAME that
      releases the correct nfsd4_secinfo_no_name structure.
      
      Fixes: 34b1744c ("nfsd4: define ->op_release for compound ops")
      Signed-off-by: NEryu Guan <eguan@redhat.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      ec572b9e
  3. 05 10月, 2017 1 次提交
  4. 25 8月, 2017 3 次提交
  5. 02 8月, 2017 1 次提交
  6. 14 7月, 2017 12 次提交
  7. 24 5月, 2017 1 次提交
    • J
      nfsd4: fix null dereference on replay · 9a307403
      J. Bruce Fields 提交于
      if we receive a compound such that:
      
      	- the sessionid, slot, and sequence number in the SEQUENCE op
      	  match a cached succesful reply with N ops, and
      	- the Nth operation of the compound is a PUTFH, PUTPUBFH,
      	  PUTROOTFH, or RESTOREFH,
      
      then nfsd4_sequence will return 0 and set cstate->status to
      nfserr_replay_cache.  The current filehandle will not be set.  This will
      cause us to call check_nfsd_access with first argument NULL.
      
      To nfsd4_compound it looks like we just succesfully executed an
      operation that set a filehandle, but the current filehandle is not set.
      
      Fix this by moving the nfserr_replay_cache earlier.  There was never any
      reason to have it after the encode_op label, since the only case where
      he hit that is when opdesc->op_func sets it.
      
      Note that there are two ways we could hit this case:
      
      	- a client is resending a previously sent compound that ended
      	  with one of the four PUTFH-like operations, or
      	- a client is sending a *new* compound that (incorrectly) shares
      	  sessionid, slot, and sequence number with a previously sent
      	  compound, and the length of the previously sent compound
      	  happens to match the position of a PUTFH-like operation in the
      	  new compound.
      
      The second is obviously incorrect client behavior.  The first is also
      very strange--the only purpose of a PUTFH-like operation is to set the
      current filehandle to be used by the following operation, so there's no
      point in having it as the last in a compound.
      
      So it's likely this requires a buggy or malicious client to reproduce.
      Reported-by: NScott Mayhew <smayhew@redhat.com>
      Cc: stable@kernel.vger.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9a307403
  8. 15 5月, 2017 12 次提交
  9. 10 5月, 2017 1 次提交
  10. 13 4月, 2017 1 次提交
    • O
      nfsd: fix oops on unsupported operation · 05b7278d
      Olga Kornievskaia 提交于
      I'm hitting the BUG in nfsd4_max_reply() at fs/nfsd/nfs4proc.c:2495 when
      client sends an operation the server doesn't support.
      
      in nfsd4_max_reply() it checks for NULL rsize_bop but a non-supported
      operation wouldn't have that set.
      
      Cc: Kinglong Mee <kinglongmee@gmail.com>
      Fixes: 2282cd2c "NFSD: Get response size before operation..."
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      05b7278d
  11. 25 2月, 2017 2 次提交
  12. 18 2月, 2017 1 次提交
  13. 01 2月, 2017 2 次提交
    • J
      nfsd: opt in to labeled nfs per export · 32ddd944
      J. Bruce Fields 提交于
      Currently turning on NFSv4.2 results in 4.2 clients suddenly seeing the
      individual file labels as they're set on the server.  This is not what
      they've previously seen, and not appropriate in may cases.  (In
      particular, if clients have heterogenous security policies then one
      client's labels may not even make sense to another.)  Labeled NFS should
      be opted in only in those cases when the administrator knows it makes
      sense.
      
      It's helpful to be able to turn 4.2 on by default, and otherwise the
      protocol upgrade seems free of regressions.  So, default labeled NFS to
      off and provide an export flag to reenable it.
      
      Users wanting labeled NFS support on an export will henceforth need to:
      
      	- make sure 4.2 support is enabled on client and server (as
      	  before), and
      	- upgrade the server nfs-utils to a version supporting the new
      	  "security_label" export flag.
      	- set that "security_label" flag on the export.
      
      This is commit may be seen as a regression to anyone currently depending
      on security labels.  We believe those cases are currently rare.
      
      Reported-by: tibbs@math.uh.edu
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      32ddd944
    • K
      NFSD: pass an integer for stable type to nfsd_vfs_write · 54bbb7d2
      Kinglong Mee 提交于
      After fae5096a "nfsd: assume writeable exportabled filesystems have
      f_sync" we no longer modify this argument.
      
      This is just cleanup, no change in functionality.
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      54bbb7d2
  14. 16 12月, 2016 1 次提交