1. 28 9月, 2016 22 次提交
  2. 23 9月, 2016 15 次提交
  3. 20 9月, 2016 3 次提交
    • C
      nfs: cover ->migratepage with CONFIG_MIGRATION · f844cd0d
      Chao Yu 提交于
      It will be more clean to use CONFIG_MIGRATION to cover nfs' private
      .migratepage in nfs_file_aops like we do in other part of nfs
      operations.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      f844cd0d
    • D
      sunrpc: fix write space race causing stalls · d48f9ce7
      David Vrabel 提交于
      Write space becoming available may race with putting the task to sleep
      in xprt_wait_for_buffer_space().  The existing mechanism to avoid the
      race does not work.
      
      This (edited) partial trace illustrates the problem:
      
         [1] rpc_task_run_action: task:43546@5 ... action=call_transmit
         [2] xs_write_space <-xs_tcp_write_space
         [3] xprt_write_space <-xs_write_space
         [4] rpc_task_sleep: task:43546@5 ...
         [5] xs_write_space <-xs_tcp_write_space
      
      [1] Task 43546 runs but is out of write space.
      
      [2] Space becomes available, xs_write_space() clears the
          SOCKWQ_ASYNC_NOSPACE bit.
      
      [3] xprt_write_space() attemts to wake xprt->snd_task (== 43546), but
          this has not yet been queued and the wake up is lost.
      
      [4] xs_nospace() is called which calls xprt_wait_for_buffer_space()
          which queues task 43546.
      
      [5] The call to sk->sk_write_space() at the end of xs_nospace() (which
          is supposed to handle the above race) does not call
          xprt_write_space() as the SOCKWQ_ASYNC_NOSPACE bit is clear and
          thus the task is not woken.
      
      Fix the race by resetting the SOCKWQ_ASYNC_NOSPACE bit in xs_nospace()
      so the second call to sk->sk_write_space() calls xprt_write_space().
      Suggested-by: NTrond Myklebust <trondmy@primarydata.com>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      cc: stable@vger.kernel.org # 4.4
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      d48f9ce7
    • J
      pnfs: add a new mechanism to select a layout driver according to an ordered list · ca440c38
      Jeff Layton 提交于
      Currently, the layout driver selection code always chooses the first one
      from the list. That's not really ideal however, as the server can send
      the list of layout types in any order that it likes. It's up to the
      client to select the best one for its needs.
      
      This patch adds an ordered list of preferred driver types and has the
      selection code sort the list of available layout drivers according to it.
      Any unrecognized layout type is sorted to the end of the list.
      
      For now, the order of preference is hardcoded, but it should be possible
      to make this configurable in the future.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NJ. Bruce Fields <bfields@fieldses.org>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      ca440c38