acrn-hypervisor

mirror of https://github.com/projectacrn/acrn-hypervisor.git synced 2026-01-15 22:54:01 +00:00

Files

Yonghua Huang b4386566ef dm: fix mevent mutex deadlock issue

'mevent_lmutex' is initialized as default type,
 while attempting to recursively lock on this
 kind of mutext results in undefined behaviour.

 Recursively lock on 'mevent_lmutex' can be detected
 in mevent thread when user tries to trigger system
 reset from user VM, in this case, user VM reboot hang.

 The backtrace for this issue:
  #1 in mevent_qlock () at core/mevent.c:93
  #2 in mevent_delete_even at core/mevent.c:357
    ===>Recursively LOCK
  #3 in mevent_delete_close at core/mevent.c:387
  #4 in acrn_timer_deinit at core/timer.c:106
  #5 in virtio_reset_dev at hw/pci/virtio/virtio.c:171
  #6 in virtio_console_reset at
     hw/pci/virtio/virtio_console.c:196
  #7 in virtio_console_destroy at
    hw/pci/virtio/virtio_console.c:1015
  #8 in virtio_console_teardown_backend at
    hw/pci/virtio/virtio_console.c:1042
  #9 in mevent_drain_del_list () at
    core/mevent.c:348 ===> 1st LOCK
  #10 in mevent_dispatch () at core/mevent.c:472
  #11 in main at core/main.c:1110

  So the root cause is:
  mevent_mutex lock is recursively locked by mevent thread
  itself (#9 for this first lock and #2 for recursively lock),
  which is not allowed for mutex with default attribute.

  This patch changes the mutex type of 'mevent_lmutex'
  from default to "PTHREAD_MUTEX_RECURSIVE", because
  recrusively lock shall be allowed as user of mevent
  may call mevent functions (where mutex lock maybe required)
  in teardown callbacks.

Tracked-On: #7133
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>