1. 30 3月, 2014 2 次提交
  2. 29 3月, 2014 1 次提交
  3. 15 1月, 2014 1 次提交
  4. 01 1月, 2014 2 次提交
  5. 11 12月, 2013 1 次提交
  6. 13 11月, 2013 1 次提交
  7. 09 11月, 2013 1 次提交
    • T
      SUNRPC: Fix a data corruption issue when retransmitting RPC calls · a6b31d18
      Trond Myklebust 提交于
      The following scenario can cause silent data corruption when doing
      NFS writes. It has mainly been observed when doing database writes
      using O_DIRECT.
      
      1) The RPC client uses sendpage() to do zero-copy of the page data.
      2) Due to networking issues, the reply from the server is delayed,
         and so the RPC client times out.
      
      3) The client issues a second sendpage of the page data as part of
         an RPC call retransmission.
      
      4) The reply to the first transmission arrives from the server
         _before_ the client hardware has emptied the TCP socket send
         buffer.
      5) After processing the reply, the RPC state machine rules that
         the call to be done, and triggers the completion callbacks.
      6) The application notices the RPC call is done, and reuses the
         pages to store something else (e.g. a new write).
      
      7) The client NIC drains the TCP socket send buffer. Since the
         page data has now changed, it reads a corrupted version of the
         initial RPC call, and puts it on the wire.
      
      This patch fixes the problem in the following manner:
      
      The ordering guarantees of TCP ensure that when the server sends a
      reply, then we know that the _first_ transmission has completed. Using
      zero-copy in that situation is therefore safe.
      If a time out occurs, we then send the retransmission using sendmsg()
      (i.e. no zero-copy), We then know that the socket contains a full copy of
      the data, and so it will retransmit a faithful reproduction even if the
      RPC call completes, and the application reuses the O_DIRECT buffer in
      the meantime.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      a6b31d18
  8. 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
  9. 29 10月, 2013 1 次提交
  10. 02 10月, 2013 2 次提交
  11. 05 9月, 2013 1 次提交
  12. 25 7月, 2013 1 次提交
  13. 13 6月, 2013 1 次提交
  14. 15 5月, 2013 1 次提交
  15. 26 4月, 2013 1 次提交
  16. 15 4月, 2013 1 次提交
  17. 26 3月, 2013 1 次提交
  18. 10 3月, 2013 1 次提交
    • J
      sunrpc: don't attempt to cancel unitialized work · 190b1ecf
      J. Bruce Fields 提交于
      As of dc107402 "SUNRPC: make AF_LOCAL connect synchronous", we no longer initialize connect_worker in the
      AF_LOCAL case, resulting in warnings like:
      
          WARNING: at lib/debugobjects.c:261 debug_print_object+0x8c/0xb0() Hardware name: Bochs
          ODEBUG: assert_init not available (active state 0) object type: timer_list hint: stub_timer+0x0/0x20
          Modules linked in: iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nfsd auth_rpcgss nfs_acl lockd sunrpc
          Pid: 4816, comm: nfsd Tainted: G        W    3.8.0-rc2-00049-gdc107402 #801
          Call Trace:
           [<ffffffff8156ec00>] ? free_obj_work+0x60/0xa0
           [<ffffffff81046aaf>] warn_slowpath_common+0x7f/0xc0
           [<ffffffff81046ba6>] warn_slowpath_fmt+0x46/0x50
           [<ffffffff8156eccc>] debug_print_object+0x8c/0xb0
           [<ffffffff81055030>] ? timer_debug_hint+0x10/0x10
           [<ffffffff8156f7e3>] debug_object_assert_init+0xe3/0x120
           [<ffffffff81057ebb>] del_timer+0x2b/0x80
           [<ffffffff8109c4e6>] ? mark_held_locks+0x86/0x110
           [<ffffffff81065a29>] try_to_grab_pending+0xd9/0x150
           [<ffffffff81065b57>] __cancel_work_timer+0x27/0xc0
           [<ffffffff81065c03>] cancel_delayed_work_sync+0x13/0x20
           [<ffffffffa0007067>] xs_destroy+0x27/0x80 [sunrpc]
           [<ffffffffa00040d8>] xprt_destroy+0x78/0xa0 [sunrpc]
           [<ffffffffa0006241>] xprt_put+0x21/0x30 [sunrpc]
           [<ffffffffa00030cf>] rpc_free_client+0x10f/0x1a0 [sunrpc]
           [<ffffffffa0002ff3>] ? rpc_free_client+0x33/0x1a0 [sunrpc]
           [<ffffffffa0002f7e>] rpc_release_client+0x6e/0xb0 [sunrpc]
           [<ffffffffa000325d>] rpc_shutdown_client+0xfd/0x1b0 [sunrpc]
           [<ffffffffa0017196>] rpcb_put_local+0x106/0x130 [sunrpc]
          ...
      Acked-by: N"Myklebust, Trond" <Trond.Myklebust@netapp.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      190b1ecf
  19. 01 3月, 2013 1 次提交
  20. 05 2月, 2013 1 次提交
  21. 01 2月, 2013 4 次提交
  22. 16 12月, 2012 2 次提交
  23. 05 11月, 2012 2 次提交
  24. 24 10月, 2012 4 次提交
  25. 29 9月, 2012 1 次提交
  26. 25 9月, 2012 1 次提交
    • B
      SUNRPC: Set alloc_slot for backchannel tcp ops · 84e28a30
      Bryan Schumaker 提交于
      f39c1bfb (SUNRPC: Fix a UDP transport
      regression) introduced the "alloc_slot" function for xprt operations,
      but never created one for the backchannel operations.  This patch fixes
      a null pointer dereference when mounting NFS over v4.1.
      
      Call Trace:
       [<ffffffffa0207957>] ? xprt_reserve+0x47/0x50 [sunrpc]
       [<ffffffffa02023a4>] call_reserve+0x34/0x60 [sunrpc]
       [<ffffffffa020e280>] __rpc_execute+0x90/0x400 [sunrpc]
       [<ffffffffa020e61a>] rpc_async_schedule+0x2a/0x40 [sunrpc]
       [<ffffffff81073589>] process_one_work+0x139/0x500
       [<ffffffff81070e70>] ? alloc_worker+0x70/0x70
       [<ffffffffa020e5f0>] ? __rpc_execute+0x400/0x400 [sunrpc]
       [<ffffffff81073d1e>] worker_thread+0x15e/0x460
       [<ffffffff8145c839>] ? preempt_schedule+0x49/0x70
       [<ffffffff81073bc0>] ? rescuer_thread+0x230/0x230
       [<ffffffff81079603>] kthread+0x93/0xa0
       [<ffffffff81465d04>] kernel_thread_helper+0x4/0x10
       [<ffffffff81079570>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff81465d00>] ? gs_change+0x13/0x13
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      84e28a30
  27. 20 9月, 2012 1 次提交
  28. 07 9月, 2012 1 次提交
    • T
      SUNRPC: Fix a UDP transport regression · f39c1bfb
      Trond Myklebust 提交于
      Commit 43cedbf0 (SUNRPC: Ensure that
      we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
      hangs in the case of NFS over UDP mounts.
      
      Since neither the UDP or the RDMA transport mechanism use dynamic slot
      allocation, we can skip grabbing the socket lock for those transports.
      Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
      case.
      
      Note that the NFSv4.1 back channel assigns the slot directly
      through rpc_run_bc_task, so we can ignore that case.
      Reported-by: NDick Streefland <dick.streefland@altium.nl>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org [>= 3.1]
      f39c1bfb