1. 24 5月, 2017 1 次提交
    • B
      pnfs: Fix the check for requests in range of layout segment · 08cb5b0f
      Benjamin Coddington 提交于
      It's possible and acceptable for NFS to attempt to add requests beyond the
      range of the current pgio->pg_lseg, a case which should be caught and
      limited by the pg_test operation.  However, the current handling of this
      case replaces pgio->pg_lseg with a new layout segment (after a WARN) within
      that pg_test operation.  That will cause all the previously added requests
      to be submitted with this new layout segment, which may not be valid for
      those requests.
      
      Fix this problem by only returning zero for the number of bytes to coalesce
      from pg_test for this case which allows any previously added requests to
      complete on the current layout segment.  The check for requests starting
      out of range of the layout segment moves to pg_init, so that the
      replacement of pgio->pg_lseg will be done when the next request is added.
      Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      08cb5b0f
  2. 03 5月, 2017 2 次提交
    • T
      pNFS: Fix a deadlock when coalescing writes and returning the layout · 61f454e3
      Trond Myklebust 提交于
      Consider the following deadlock:
      
      Process P1	Process P2		Process P3
      ==========	==========		==========
      					lock_page(page)
      
      		lseg = pnfs_update_layout(inode)
      
      lo = NFS_I(inode)->layout
      pnfs_error_mark_layout_for_return(lo)
      
      		lock_page(page)
      
      					lseg = pnfs_update_layout(inode)
      
      In this scenario,
      - P1 has declared the layout to be in error, but P2 holds a reference to
        a layout segment on that inode, so the layoutreturn is deferred.
      - P2 is waiting for a page lock held by P3.
      - P3 is asking for a new layout segment, but is blocked waiting
        for the layoutreturn.
      
      The fix is to ensure that pnfs_error_mark_layout_for_return() does
      not set the NFS_LAYOUT_RETURN flag, which blocks P3. Instead, we allow
      the latter to call LAYOUTGET so that it can make progress and unblock
      P2.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      61f454e3
    • T
      pNFS: Don't clear the layout return info if there are segments to return · 5466d214
      Trond Myklebust 提交于
      In pnfs_clear_layoutreturn_info, ensure that we don't clear the layout
      return info if there are new segments queued for return due to, for
      instance, a race between a LAYOUTRETURN and a failed I/O attempt.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      5466d214
  3. 29 4月, 2017 3 次提交
  4. 26 4月, 2017 1 次提交
  5. 25 4月, 2017 1 次提交
  6. 21 4月, 2017 1 次提交
  7. 27 1月, 2017 1 次提交
  8. 20 12月, 2016 1 次提交
  9. 06 12月, 2016 1 次提交
  10. 04 12月, 2016 1 次提交
  11. 03 12月, 2016 1 次提交
  12. 02 12月, 2016 20 次提交
  13. 08 11月, 2016 1 次提交
  14. 28 9月, 2016 1 次提交
  15. 20 9月, 2016 2 次提交
  16. 05 9月, 2016 1 次提交
    • T
      pNFS: Don't forget the layout stateid if there are outstanding LAYOUTGETs · 334a8f37
      Trond Myklebust 提交于
      If there are outstanding LAYOUTGET rpc calls, then we want to ensure that
      we keep the layout stateid around so we that don't inadvertently pick up
      an old/misordered sequence id.
      The race is as follows:
      
      Client				Server
      ======				======
      LAYOUTGET(seqid)
      LAYOUTGET(seqid)
      				return LAYOUTGET(seqid+1)
      				return LAYOUTGET(seqid+2)
      process LAYOUTGET(seqid+2)
      	forget layout
      process LAYOUTGET(seqid+1)
      
      If it forgets the layout stateid before processing seqid+1, then
      the client will not check the layout->plh_barrier, and so will set
      the stateid with seqid+1.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      334a8f37
  17. 04 9月, 2016 1 次提交