1. 15 1月, 2018 1 次提交
  2. 01 12月, 2017 1 次提交
  3. 18 11月, 2017 2 次提交
  4. 07 9月, 2017 1 次提交
    • N
      SUNRPC: remove some dead code. · f1ecbc21
      NeilBrown 提交于
      RPC_TASK_NO_RETRANS_TIMEOUT is set when cl_noretranstimeo
      is set, which happens when  RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT is set,
      which happens when NFS_CS_NO_RETRANS_TIMEOUT is set.
      
      This flag means "don't resend on a timeout, only resend if the
      connection gets broken for some reason".
      
      cl_discrtry is set when RPC_CLNT_CREATE_DISCRTRY is set, which
      happens when NFS_CS_DISCRTRY is set.
      
      This flag means "always disconnect before resending".
      
      NFS_CS_NO_RETRANS_TIMEOUT and NFS_CS_DISCRTRY are both only set
      in nfs4_init_client(), and it always sets both.
      
      So we will never have a situation where only one of the flags is set.
      So this code, which tests if timeout retransmits are allowed, and
      disconnection is required, will never run.
      
      So it makes sense to remove this code as it cannot be tested and
      could confuse people reading the code (like me).
      
      (alternately we could leave it there with a comment saying
       it is never actually used).
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      f1ecbc21
  5. 21 8月, 2017 1 次提交
    • N
      SUNRPC: ECONNREFUSED should cause a rebind. · fd01b259
      NeilBrown 提交于
      If you
       - mount and NFSv3 filesystem
       - do some file locking which requires the server
         to make a GRANT call back
       - unmount
       - mount again and do the same locking
      
      then the second attempt at locking suffers a 30 second delay.
      Unmounting and remounting causes lockd to stop and restart,
      which causes it to bind to a new port.
      The server still thinks the old port is valid and gets ECONNREFUSED
      when trying to contact it.
      ECONNREFUSED should be seen as a hard error that is not worth
      retrying.  Rebinding is the only reasonable response.
      
      This patch forces a rebind if that makes sense.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      fd01b259
  6. 14 7月, 2017 4 次提交
  7. 15 5月, 2017 4 次提交
  8. 21 4月, 2017 1 次提交
  9. 10 2月, 2017 3 次提交
  10. 25 1月, 2017 1 次提交
    • K
      SUNRPC: cleanup ida information when removing sunrpc module · c929ea0b
      Kinglong Mee 提交于
      After removing sunrpc module, I get many kmemleak information as,
      unreferenced object 0xffff88003316b1e0 (size 544):
        comm "gssproxy", pid 2148, jiffies 4294794465 (age 4200.081s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffffb0cfb58a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffffb03507fe>] kmem_cache_alloc+0x15e/0x1f0
          [<ffffffffb0639baa>] ida_pre_get+0xaa/0x150
          [<ffffffffb0639cfd>] ida_simple_get+0xad/0x180
          [<ffffffffc06054fb>] nlmsvc_lookup_host+0x4ab/0x7f0 [lockd]
          [<ffffffffc0605e1d>] lockd+0x4d/0x270 [lockd]
          [<ffffffffc06061e5>] param_set_timeout+0x55/0x100 [lockd]
          [<ffffffffc06cba24>] svc_defer+0x114/0x3f0 [sunrpc]
          [<ffffffffc06cbbe7>] svc_defer+0x2d7/0x3f0 [sunrpc]
          [<ffffffffc06c71da>] rpc_show_info+0x8a/0x110 [sunrpc]
          [<ffffffffb044a33f>] proc_reg_write+0x7f/0xc0
          [<ffffffffb038e41f>] __vfs_write+0xdf/0x3c0
          [<ffffffffb0390f1f>] vfs_write+0xef/0x240
          [<ffffffffb0392fbd>] SyS_write+0xad/0x130
          [<ffffffffb0d06c37>] entry_SYSCALL_64_fastpath+0x1a/0xa9
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      I found, the ida information (dynamic memory) isn't cleanup.
      Signed-off-by: NKinglong Mee <kinglongmee@gmail.com>
      Fixes: 2f048db4 ("SUNRPC: Add an identifier for struct rpc_clnt")
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      c929ea0b
  11. 02 12月, 2016 1 次提交
    • N
      sunrpc: Don't engage exponential backoff when connection attempt is rejected. · 2c2ee6d2
      NeilBrown 提交于
      xs_connect() contains an exponential backoff mechanism so the repeated
      connection attempts are delayed by longer and longer amounts.
      
      This is appropriate when the connection failed due to a timeout, but
      it not appropriate when a definitive "no" answer is received.  In such
      cases, call_connect_status() imposes a minimum 3-second back-off, so
      not having the exponetial back-off will never result in immediate
      retries.
      
      The current situation is a problem when the NFS server tries to
      register with rpcbind but rpcbind isn't running.  All connection
      attempts are made on the same "xprt" and as the connection is never
      "closed", the exponential back delays successive attempts to register,
      or de-register, different protocols.  This results in a multi-minute
      delay with no benefit.
      
      So, when call_connect_status() receives a definitive "no", use
      xprt_conditional_disconnect() to cancel the previous connection attempt.
      This will set XPRT_CLOSE_WAIT so that xprt->ops->close() calls xs_close()
      which resets the reestablish_timeout.
      
      To ensure xprt_conditional_disconnect() does the right thing, we
      ensure that rq_connect_cookie is set before a connection attempt, and
      allow xprt_conditional_disconnect() to complete even when the
      transport is not fully connected.
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      2c2ee6d2
  12. 08 11月, 2016 1 次提交
  13. 20 9月, 2016 9 次提交
  14. 25 8月, 2016 1 次提交
  15. 06 8月, 2016 2 次提交
  16. 25 7月, 2016 1 次提交
  17. 15 6月, 2016 3 次提交
  18. 18 5月, 2016 1 次提交
  19. 06 2月, 2016 2 次提交