netdev - Re: [PATCH] vhost: Use mutex to protect vq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Oct 2020 16:08:24 +0800
From:   Jason Wang <jasowang@...hat.com>
To:     Eli Cohen <elic@...dia.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        virtualization@...ts.linux-foundation.org,
        netdev <netdev@...r.kernel.org>, lingshan.zhu@...el.com
Subject: Re: [PATCH] vhost: Use mutex to protect vq_irq setup


On 2020/10/29 下午3:50, Eli Cohen wrote:
> On Thu, Oct 29, 2020 at 03:39:24PM +0800, Jason Wang wrote:
>> On 2020/10/29 下午3:37, Eli Cohen wrote:
>>> On Thu, Oct 29, 2020 at 03:03:24PM +0800, Jason Wang wrote:
>>>> On 2020/10/28 下午10:20, Eli Cohen wrote:
>>>>> Both irq_bypass_register_producer() and irq_bypass_unregister_producer()
>>>>> require process context to run. Change the call context lock from
>>>>> spinlock to mutex to protect the setup process to avoid deadlocks.
>>>>>
>>>>> Fixes: 265a0ad8731d ("vhost: introduce vhost_vring_call")
>>>>> Signed-off-by: Eli Cohen<elic@...dia.com>
>>>> Hi Eli:
>>>>
>>>> During review we spot that the spinlock is not necessary. And it was already
>>>> protected by vq mutex. So it was removed in this commit:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86e182fe12ee5869022614457037097c70fe2ed1
>>>>
>>>> Thanks
>>>>
>>> I see, thanks.
>>>
>>> BTW, while testing irq bypassing, I noticed that qemu started crashing
>>> and I fail to boot the VM? Is that a known issue. I checked using
>>> updated master branch of qemu updated yesterday.
>> Not known yet.
>>
>>
>>> Any ideas how to check this further?
>> I would be helpful if you can paste the calltrace here.
>>
> I am not too familiar with qemu. Assuming I am using virsh start to boot
> the VM, how can I get the call trace?


You probably need to configure qemu with --enable-debug. Then after VM 
is launching, you can use gdb to attach to the qemu process, then gdb 
may report a calltrace if qemu crashes.

Thanks