1. 04 11月, 2017 1 次提交
  2. 31 10月, 2017 2 次提交
  3. 04 10月, 2017 2 次提交
  4. 17 8月, 2017 1 次提交
  5. 10 8月, 2017 1 次提交
  6. 25 5月, 2017 1 次提交
  7. 18 5月, 2017 1 次提交
  8. 17 3月, 2017 2 次提交
  9. 16 3月, 2017 1 次提交
  10. 02 3月, 2017 1 次提交
  11. 15 2月, 2017 3 次提交
  12. 10 2月, 2017 1 次提交
  13. 31 1月, 2017 1 次提交
  14. 20 1月, 2017 1 次提交
  15. 11 1月, 2017 2 次提交
  16. 06 12月, 2016 1 次提交
  17. 01 11月, 2016 1 次提交
  18. 27 9月, 2016 1 次提交
  19. 07 9月, 2016 1 次提交
  20. 31 8月, 2016 1 次提交
  21. 13 6月, 2016 1 次提交
  22. 02 5月, 2016 1 次提交
    • V
      Drivers: hv: vmbus: handle various crash scenarios · cd95aad5
      Vitaly Kuznetsov 提交于
      Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
      delivered to the CPU which was used for initial contact or to CPU0
      depending on host version. vmbus_wait_for_unload() doesn't account for
      the fact that in case we're crashing on some other CPU we won't get the
      CHANNELMSG_UNLOAD_RESPONSE message and our wait on the current CPU will
      never end.
      
      Do the following:
      1) Check for completion_done() in the loop. In case interrupt handler is
         still alive we'll get the confirmation we need.
      
      2) Read message pages for all CPUs message page as we're unsure where
         CHANNELMSG_UNLOAD_RESPONSE is going to be delivered to. We can race with
         still-alive interrupt handler doing the same, add cmpxchg() to
         vmbus_signal_eom() to not lose CHANNELMSG_UNLOAD_RESPONSE message.
      
      3) Cleanup message pages on all CPUs. This is required (at least for the
         current CPU as we're clearing CPU0 messages now but we may want to bring
         up additional CPUs on crash) as new messages won't be delivered till we
         consume what's pending. On boot we'll place message pages somewhere else
         and we won't be able to read stale messages.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd95aad5
  23. 01 5月, 2016 6 次提交
  24. 02 3月, 2016 4 次提交
  25. 08 2月, 2016 2 次提交