'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>
If a file descriptor being monitored by epoll_wait is closed
in another thread, the result is unspecified. So add all mevents
removed in other threads to delete list. And drain the list in
the dispatch mevent thread.
Tracked-On: #6877
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Unify two functions definitions/declarifications:
Update the parameters from char array to char pointer.
to fix the build issue:
probeutils.c:61:29: error: argument 1 of type 'char *' declared
as a pointer [-Werror=array-parameter=]
Initialize local variable "c" to fix build issue:
core/mevent.c:122:21: error: 'c' may be used uninitialized
[-Werror=maybe-uninitialized]
Tracked-On: #5993
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
use acrn-dm logger function instread of perror,
this helps the stability testing log capture.
Tracked-On: #4098
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
use acrn-dm logger function instread of fprintf,
this helps the stability testing log capture.
Tracked-On: #4098
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Cao Minggui <minggui.cao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Remove unnecessary assert and add error handling when required.
Tracked-On: #3252
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
It was designed to be used in non-blocking mode to prevent the mevent
thread from blocking itself indefinitely, but it was created in
blocking mode.
Tracked-On: #2319
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Pass teardown callback when add mevent in mei mediator code.
Which could avoid run_callback calling after the related data
structure is freed.
Tracked-On: #1877
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
There is one race issue between mevent callback (which is called
in mevent_dispatch thread) and mevent_delete (which could be called
in dev thread). And the callback is called after mevent_delete.
libevent have the exactly same issue. The issue is decripted here:
https://github.com/libevent/libevent/blob/master/whatsnew-2.1.txt
The fixing is:
We introduce a teardown callback to mevent and make sure there is
no race issue between callback and teardown call.
This patch updates the mevent API and the caller as well.
Tracked-On: #1877
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Peter, Thomas and Shuo raised one race issue in mevent_del. It
happens like following:
Thread mevent_dispatch Thread
mevent_delete_event
epoll_ctl_del
free(evp)
mevent_handle with freed evp
The fixing is adding sync between mevent_delete_event and
mevent_handle in mevent_dispatch.
Thread mevent_dispatch Thread
mevent_delete_event
add evp to del_list
notify mevent_dispatch
return
mevent_handle
Remove evp from del_list
Remove evp from epoll_fd
closefd()
free(evp)
Tracked-On: #1877
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Added edge triggered read and write events.
For mei mediator we need to detect changes in
sysfs files, it's not possible to do it via
level based triggers as the files are always
readable.
Tracked-On: #1417
Change-Id: Ib360ad31f30afa576b2b7b833f9bb139c269a030
Signed-off-by: Aviad Nissel <aviad.nissel@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Current mevent mevent_del/add() implementations are incomplete and buggy.
It's easier to implement mevent_enable/disable() required for mei
virtualization. Other user of these functions, which were previously
empty stubs is the uart mediator, so far it looks working well.
Add few style issues fix on the way.
Tracked-On: #1416
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
We do:
- pause target vm
- suspend all virtual devices
- wait for resume notification
- resume all virtual devices
- reset target vm
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Guest has erquirement to support system/full reboot and S3. Which could
trigger different reset path in guest
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Unlike kqueue/kevent of BSD, the epoll of Linux could be
add/del by using different API on the fly.
This patch drops the notify used by mevent_add/del and
call epoll_ctl to add/delete target fd. Only keeps
global_head to track mevent added and makes the code
logic in mevent_dispatch() a littel bit simpler.
Another thing is related with epoll_ctl. If the target
fd is regular fd which doesn't support epoll, epoll_ctl
will return -1. When DM is start by systemd, the STDIO
is not mapped to terminal, epoll_ctl on STDIO could
return -1. Which block UOS boot. We only call mevent_add
after confirm STDIO is mapped to terminal.
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Current, mevent cleanup path has issue. There are possible
following calling sequence happen when reboot/poweroff UOS:
1. mevent_dispatch() calls mevent_destroy
2. do_close_post calls some virtual device deinit to delete
mevent.
This patch introduce mevent init/deinit to make sure:
1. mevent init
2. mevent_add is called when init virtual device
3. mevent_del is called when deinit virtual device
4. mevent deinit
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Yonghua Huang