1. 01 11月, 2013 1 次提交
  2. 31 10月, 2013 2 次提交
    • T
      SUNRPC: Cleanup xs_destroy() · a1311d87
      Trond Myklebust 提交于
      There is no longer any need for a separate xs_local_destroy() helper.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      a1311d87
    • N
      SUNRPC: close a rare race in xs_tcp_setup_socket. · 93dc41bd
      NeilBrown 提交于
      We have one report of a crash in xs_tcp_setup_socket.
      The call path to the crash is:
      
        xs_tcp_setup_socket -> inet_stream_connect -> lock_sock_nested.
      
      The 'sock' passed to that last function is NULL.
      
      The only way I can see this happening is a concurrent call to
      xs_close:
      
        xs_close -> xs_reset_transport -> sock_release -> inet_release
      
      inet_release sets:
         sock->sk = NULL;
      inet_stream_connect calls
         lock_sock(sock->sk);
      which gets NULL.
      
      All calls to xs_close are protected by XPRT_LOCKED as are most
      activations of the workqueue which runs xs_tcp_setup_socket.
      The exception is xs_tcp_schedule_linger_timeout.
      
      So presumably the timeout queued by the later fires exactly when some
      other code runs xs_close().
      
      To protect against this we can move the cancel_delayed_work_sync()
      call from xs_destory() to xs_close().
      
      As xs_close is never called from the worker scheduled on
      ->connect_worker, this can never deadlock.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      [Trond: Make it safe to call cancel_delayed_work_sync() on AF_LOCAL sockets]
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      93dc41bd
  3. 30 10月, 2013 1 次提交
  4. 29 10月, 2013 36 次提交