Thread (8 messages) 8 messages, 3 authors, 2020-10-29

Re: [PATCH] vhost: Use mutex to protect vq_irq setup

From: Eli Cohen <hidden>
Date: 2020-10-29 10:09:18

On Thu, Oct 29, 2020 at 04:08:24PM +0800, Jason Wang wrote:
On 2020/10/29 下午3:50, Eli Cohen wrote:
quoted
On Thu, Oct 29, 2020 at 03:39:24PM +0800, Jason Wang wrote:
quoted
On 2020/10/29 下午3:37, Eli Cohen wrote:
quoted
On Thu, Oct 29, 2020 at 03:03:24PM +0800, Jason Wang wrote:
quoted
On 2020/10/28 下午10:20, Eli Cohen wrote:
quoted
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<redacted>
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.

quoted
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.
I run qemu from the console (no virsh) and I get this message:

*** stack smashing detected ***: terminated
Aborted (core dumped)

When I run coredumpctl debug on the core file I see this backtrace:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f0ca5b95895 in __GI_abort () at abort.c:79
#2  0x00007f0ca5bf0857 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f0ca5d01c14 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007f0ca5c8177a in __GI___fortify_fail (msg=msg@entry=0x7f0ca5d01bfc "stack smashing detected") at fortify_fail.c:26
#4  0x00007f0ca5c81746 in __stack_chk_fail () at stack_chk_fail.c:24
#5  0x000055ce01cd4d4e in vhost_vdpa_set_backend_cap (dev=0x55ce03800370) at ../hw/virtio/vhost-vdpa.c:256
#6  0x000055ce01cbc42c in vhost_dev_set_features (dev=dev@entry=0x55ce03800370, enable_log=<optimized out>) at ../hw/virtio/vhost.c:820
#7  0x000055ce01cbf5b8 in vhost_dev_start (hdev=hdev@entry=0x55ce03800370, vdev=vdev@entry=0x55ce045edc70) at ../hw/virtio/vhost.c:1701
#8  0x000055ce01a57eab in vhost_net_start_one (dev=0x55ce045edc70, net=0x55ce03800370) at ../hw/net/vhost_net.c:246
#9  vhost_net_start (dev=dev@entry=0x55ce045edc70, ncs=0x55ce04601510, total_queues=total_queues@entry=1) at ../hw/net/vhost_net.c:351
#10 0x000055ce01cdafbc in virtio_net_vhost_status (status=<optimized out>, n=0x55ce045edc70) at ../hw/net/virtio-net.c:281
#11 virtio_net_set_status (vdev=0x55ce045edc70, status=<optimized out>) at ../hw/net/virtio-net.c:362
#12 0x000055ce01c7015b in virtio_set_status (vdev=vdev@entry=0x55ce045edc70, val=val@entry=15 '\017') at ../hw/virtio/virtio.c:1957
#13 0x000055ce01bdf4e8 in virtio_pci_common_write (opaque=0x55ce045e5ae0, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at ../hw/virtio/virtio-pci.c:1258
#14 0x000055ce01ce05fc in memory_region_write_accessor
    (mr=mr@entry=0x55ce045e64c0, addr=20, value=value@entry=0x7f0c9ec6f7b8, size=size@entry=1, shift=<optimized out>, mask=mask@entry=255, attrs=...) at ../softmmu/memory.c:484
#15 0x000055ce01cdf11e in access_with_adjusted_size
    (addr=addr@entry=20, value=value@entry=0x7f0c9ec6f7b8, size=size@entry=1, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=
    0x55ce01ce0570 <memory_region_write_accessor>, mr=0x55ce045e64c0, attrs=...) at ../softmmu/memory.c:545
#16 0x000055ce01ce2933 in memory_region_dispatch_write (mr=mr@entry=0x55ce045e64c0, addr=20, data=<optimized out>, op=<optimized out>, attrs=attrs@entry=...)
    at ../softmmu/memory.c:1494
#17 0x000055ce01c81380 in flatview_write_continue
    (fv=fv@entry=0x7f0980000b90, addr=addr@entry=4261412884, attrs=attrs@entry=..., ptr=ptr@entry=0x7f0ca674f028, len=len@entry=1, addr1=<optimized out>, l=<optimized out>, mr=0x55ce045e64c0) at
/images/eli/src/newgits/qemu/include/qemu/host-utils.h:164
#18 0x000055ce01c842c5 in flatview_write (len=1, buf=0x7f0ca674f028, attrs=..., addr=4261412884, fv=0x7f0980000b90) at ../softmmu/physmem.c:2807
#19 address_space_write (as=0x55ce02740800 <address_space_memory>, addr=4261412884, attrs=..., buf=buf@entry=0x7f0ca674f028, len=1) at ../softmmu/physmem.c:2899
#20 0x000055ce01c8435a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., 
    attrs@entry=..., buf=buf@entry=0x7f0ca674f028, len=<optimized out>, is_write=<optimized out>) at ../softmmu/physmem.c:2909
#21 0x000055ce01cb0d76 in kvm_cpu_exec (cpu=cpu@entry=0x55ce03827620) at ../accel/kvm/kvm-all.c:2539
#22 0x000055ce01d2ea75 in kvm_vcpu_thread_fn (arg=arg@entry=0x55ce03827620) at ../accel/kvm/kvm-cpus.c:49
#23 0x000055ce01f05559 in qemu_thread_start (args=0x7f0c9ec6f9b0) at ../util/qemu-thread-posix.c:521
#24 0x00007f0ca5d43432 in start_thread (arg=<optimized out>) at pthread_create.c:477
#25 0x00007f0ca5c71913 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The assert at frame 5 looks to me false.


Thanks
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help