因为qemu的usb重定向,接收来自chardev和来自虚拟机的请求,是两个线程
这里就存在,两个线程同时访问一个packet的可能,导致内存异常,进一步引起逻辑错误或者崩溃
为了修改这个问题,我尝试给cancel请求和chardev的时间处理加锁处理,结果发现在某些情况变死锁了
见下图
原因:chardev时间处理中,间接调用了cancel(detach逻辑)导致死锁
解决方法:chardev的事件处理中,不掉用加锁逻辑,只在读事件中加锁
原始问题:
qemu usb重定向,多线程问题
qemu的redirect模块中,
来自虚拟机的请求(即注册在class中的请求)和来自客户端的请求(即注册在chardev上的请求)处于两个线程
1 | //来自虚拟机的请求 |
1 | //来自客户端的请求 |
1 | static void usbredir_chardev_read(void *opaque, const uint8_t *buf, int size) |
两个线程可能会同时访问各种资源,包括但不限于device,packet等
正常情况下usb请求多为顺序的,两者不回产生互相之间的影响,但是某些极端模式下,如cancel请求,断开链接这些情况,会导致两个线程共同访问资源,引起异常
为了解决这种问题,这里我尝试加入线程锁,来保护资源的访问,但是却并不如意
主要是,来自客户端的请求,包括disconnect请求,和断开事件等,都会在处理的调用栈中,调用到注册在class中的来自虚拟机的请求。这导致简单的加锁,很容易引起死锁问题
目前尚未确认注册为定时函数的函数处理线程,是否和来自虚拟机的请求属于同一线程,如果是的话,可以基于此处进行修改。
- 本文作者: crazyboy
- 本文链接: http://crazyboy.www.crazyboy.info/blog/blog/2022/04/04/it/linux/qemu/qemu-deadlock/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!