1. 05 8月, 2016 4 次提交
    • J
      nfsd: reorganize nfsd_create · b44061d0
      J. Bruce Fields 提交于
      There's some odd logic in nfsd_create() that allows it to be called with
      the parent directory either locked or unlocked.  The only already-locked
      caller is NFSv2's nfsd_proc_create().  It's less confusing to split out
      the unlocked case into a separate function which the NFSv2 code can call
      directly.
      
      Also fix some comments while we're here.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b44061d0
    • J
      nfsd: check d_can_lookup in fh_verify of directories · e75b23f9
      J. Bruce Fields 提交于
      Create and other nfsd ops generally assume we can call lookup_one_len on
      inodes with S_IFDIR set.  Al says that this assumption isn't true in
      general, though it should be for the filesystem objects nfsd sees.
      
      Add a check just to make sure our assumption isn't violated.
      
      Remove a couple checks for i_op->lookup in create code.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      e75b23f9
    • J
      nfsd: remove redundant zero-length check from create · 12391d07
      J. Bruce Fields 提交于
      lookup_one_len already has this check.
      
      The only effect of this patch is to return access instead of perm in the
      0-length-filename case.  I actually prefer nfserr_perm (or _inval?), but
      I doubt anyone cares.
      
      The isdotent check seems redundant too, but I worry that some client
      might actually care about that strange nfserr_exist error.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      12391d07
    • O
      nfsd: Make creates return EEXIST instead of EACCES · 7eed34f1
      Oleg Drokin 提交于
      When doing a create (mkdir/mknod) on a name, it's worth
      checking the name exists first before returning EACCES in case
      the directory is not writeable by the user.
      This makes return values on the client more consistent
      regardless of whenever the entry there is cached in the local
      cache or not.
      Another positive side effect is certain programs only expect
      EEXIST in that case even despite POSIX allowing any valid
      error to be returned.
      Signed-off-by: NOleg Drokin <green@linuxhacker.ru>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7eed34f1
  2. 02 8月, 2016 2 次提交
    • T
      SUNRPC: Detect immediate closure of accepted sockets · c7995f8a
      Trond Myklebust 提交于
      This modification is useful for debugging issues that happen while
      the socket is being initialised.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c7995f8a
    • T
      SUNRPC: accept() may return sockets that are still in SYN_RECV · b2f21f7d
      Trond Myklebust 提交于
      We're seeing traces of the following form:
      
       [10952.396347] svc: transport ffff88042ba4a 000 dequeued, inuse=2
       [10952.396351] svc: tcp_accept ffff88042ba4 a000 sock ffff88042a6e4c80
       [10952.396362] nfsd: connect from 10.2.6.1, port=187
       [10952.396364] svc: svc_setup_socket ffff8800b99bcf00
       [10952.396368] setting up TCP socket for reading
       [10952.396370] svc: svc_setup_socket created ffff8803eb10a000 (inet ffff88042b75b800)
       [10952.396373] svc: transport ffff8803eb10a000 put into queue
       [10952.396375] svc: transport ffff88042ba4a000 put into queue
       [10952.396377] svc: server ffff8800bb0ec000 waiting for data (to = 3600000)
       [10952.396380] svc: transport ffff8803eb10a000 dequeued, inuse=2
       [10952.396381] svc_recv: found XPT_CLOSE
       [10952.396397] svc: svc_delete_xprt(ffff8803eb10a000)
       [10952.396398] svc: svc_tcp_sock_detach(ffff8803eb10a000)
       [10952.396399] svc: svc_sock_detach(ffff8803eb10a000)
       [10952.396412] svc: svc_sock_free(ffff8803eb10a000)
      
      i.e. an immediate close of the socket after initialisation.
      
      The culprit appears to be the test at the end of svc_tcp_init, which
      checks if the newly created socket is in the TCP_ESTABLISHED state,
      and immediately closes it if not. The evidence appears to suggest that
      the socket might still be in the SYN_RECV state at this time.
      
      The fix is to check for both states, and then to add a check in
      svc_tcp_state_change() to ensure we don't close the socket when
      it transitions into TCP_ESTABLISHED.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b2f21f7d
  3. 16 7月, 2016 4 次提交
  4. 14 7月, 2016 17 次提交
  5. 02 7月, 2016 1 次提交
  6. 01 7月, 2016 2 次提交
  7. 27 6月, 2016 2 次提交
  8. 25 6月, 2016 8 次提交