1. 21 7月, 2016 2 次提交
    • J
      dm thin: fix a race condition between discarding and provisioning a block · 2a0fbffb
      Joe Thornber 提交于
      The discard passdown was being issued after the block was unmapped,
      which meant the block could be reprovisioned whilst the passdown discard
      was still in flight.
      
      We can only identify unshared blocks (safe to do a passdown a discard
      to) once they're unmapped and their ref count hits zero.  Block ref
      counts are now used to guard against concurrent allocation of these
      blocks that are being discarded.  So now we unmap the block, issue
      passdown discards, and the immediately increment ref counts for regions
      that have been discarded via passed down (this is safe because
      allocation occurs within the same thread).  We then decrement ref counts
      once the passdown discard IO is complete -- signaling these blocks may
      now be allocated.
      
      This fixes the potential for corruption that was reported here:
      https://www.redhat.com/archives/dm-devel/2016-June/msg00311.htmlReported-by: NDennis Yang <dennisyang@qnap.com>
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      2a0fbffb
    • J
      dm btree: fix a bug in dm_btree_find_next_single() · e7e0f730
      Joe Thornber 提交于
      dm_btree_find_next_single() can short-circuit the search for a block
      with a return of -ENODATA if all entries are higher than the search key
      passed to lower_bound().
      
      This hasn't been a problem because of the way the btree has been used by
      DM thinp.  But it must be fixed now in preparation for fixing the race
      in DM thinp's handling of simultaneous block discard vs allocation.
      Otherwise, once that fix is in place, some of the blocks in a discard
      would not be unmapped as expected.
      Signed-off-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      e7e0f730
  2. 19 7月, 2016 29 次提交
  3. 06 7月, 2016 1 次提交
  4. 02 7月, 2016 1 次提交
  5. 01 7月, 2016 2 次提交
  6. 17 6月, 2016 1 次提交
  7. 15 6月, 2016 4 次提交