1. 15 5月, 2017 2 次提交
  2. 21 4月, 2017 1 次提交
  3. 10 2月, 2017 3 次提交
  4. 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
  5. 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
  6. 08 11月, 2016 1 次提交
  7. 20 9月, 2016 9 次提交
  8. 25 8月, 2016 1 次提交
  9. 06 8月, 2016 2 次提交
  10. 25 7月, 2016 1 次提交
  11. 15 6月, 2016 3 次提交
  12. 18 5月, 2016 1 次提交
  13. 06 2月, 2016 5 次提交
  14. 01 2月, 2016 1 次提交
  15. 31 12月, 2015 1 次提交
  16. 03 7月, 2015 1 次提交
  17. 20 6月, 2015 1 次提交
  18. 11 6月, 2015 4 次提交
  19. 05 6月, 2015 1 次提交