Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: doc test, don't merge #3

Open
wants to merge 1 commit into
base: release_2.7
Choose a base branch
from
Open

doc: doc test, don't merge #3

wants to merge 1 commit into from

Conversation

szhen11
Copy link
Owner

@szhen11 szhen11 commented Dec 9, 2021

Signed-off-by: Shuang Zheng shuang.zheng@intel.com

@acrnsi-robot
Copy link
Collaborator

Can one of the admins verify this patch?

@szhen11 szhen11 force-pushed the doc_test_2.7 branch 29 times, most recently from cbc1841 to 4405af2 Compare December 10, 2021 01:37
@szhen11 szhen11 force-pushed the doc_test_2.7 branch 3 times, most recently from 12fd24c to 64357ae Compare December 15, 2021 02:24
Signed-off-by: Shuang Zheng <shuang.zheng@intel.com>
szhen11 pushed a commit that referenced this pull request Mar 10, 2022
 '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
  projectacrn#9 in mevent_drain_del_list () at
    core/mevent.c:348 ===> 1st LOCK
  projectacrn#10 in mevent_dispatch () at core/mevent.c:472
  projectacrn#11 in main at core/main.c:1110

  So the root cause is:
  mevent_mutex lock is recursively locked by mevent thread
  itself (projectacrn#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: projectacrn#7133
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants