1. 29 3月, 2013 2 次提交
  2. 09 11月, 2012 3 次提交
  3. 08 11月, 2012 11 次提交
  4. 04 11月, 2012 2 次提交
  5. 30 10月, 2012 2 次提交
  6. 10 5月, 2012 1 次提交
  7. 09 5月, 2012 1 次提交
  8. 14 10月, 2011 3 次提交
  9. 28 9月, 2011 1 次提交
  10. 25 8月, 2011 1 次提交
  11. 24 5月, 2011 2 次提交
  12. 31 3月, 2011 1 次提交
  13. 10 3月, 2011 7 次提交
  14. 22 10月, 2010 1 次提交
  15. 15 10月, 2010 2 次提交
    • L
      drbd: add race-breaker to drbd_go_diskless · 5dbfe7ae
      Lars Ellenberg 提交于
      This adds a necessary race breaker to these commits:
          drbd: fix for possible deadlock on IO error during resync
          drbd: drop wrong debug asserts, fix recently introduced race
      
      What we do is get a refcount, check the state, then depending on the
      state and the requested minimum disk state, either hold it (success),
      or give it back immediately (failed "try lock").
      
      Some code paths (flushing of drbd metadata) may still grab and hold a
      refcount even if we are D_FAILED (application IO won't).
      So even if we hit local_cnt == 0 once after being D_FAILED,
      we still need to wait for that again after we changed to D_DISKLESS.
      Once local_cnt reaches 0 while we are D_DISKLESS, we can be sure that
      no one will look at the protected members anymore, so only then is it
      safe to free them.
      
      We cannot easily convert to standard locking primitives here, as we want
      to be able to use it in atomic context (we always do a "try lock"),
      as well as hold references for a "long time" (from IO submission to
      completion callback).
      Signed-off-by: NPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: NLars Ellenberg <lars.ellenberg@linbit.com>
      5dbfe7ae
    • L
      drbd: fix unlikely access after free and list corruption · 22cc37a9
      Lars Ellenberg 提交于
      Various cleanup paths have been incomplete, for the very unlikely case
      that we cannot allocate enough bios from process context when submitting
      on behalf of the peer or resync process.
      
      Never observed.
      Signed-off-by: NPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: NLars Ellenberg <lars.ellenberg@linbit.com>
      22cc37a9