Libvhost user #1

franciozzy · 2016-10-14T11:27:43Z

These are my fixes for libvhost-user which were necessary for the vhost-user-scsi sample application to work. I didn't add any of the nits we discussed over e-mail. Those can be done at a later time.

This patch fix three simple errors that are preventing libvhost-user from building. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

When configuring VQs, Qemu will tell the backend where to start processing the avail ring with a SET_VRING_BASE message. However, there is no explicit message to tell the backend where to start processing the used ring. This patch updates the local copy of a vq's used_idx upon seeing a SET_VRING_ADDR message. The used ring may have changed if the driver has been reloaded, for example, or between SeaBIOS using the device and then the kernel loading the relevant virtio module. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

The shadow copy of the last_avail_idx must also be updated upon receiving a SET_VRING_BASE message. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

Currently, VQs are only marked as started or stopped when queue_set_started() is configured during vu_init(). This patch mark VQs as started/stopped regardless. This field might be useful for other changes in the near future. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

Currently, VQs are started as soon as a SET_VRING_KICK is received. That is too early in the VQ setup process, as the backend might not yet have a callfd to notify in case it received a kick and fully processed the request/command. This patch only starts a VQ when a SET_VRING_CALL is received. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

Qemu crash in the source side while migrating, after starting ipmi service inside vm. ./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 \ -drive file=/work/suse/suse11_sp3_64_vt,format=raw,if=none,id=drive-virtio-disk0,cache=none \ -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \ -vnc :99 -monitor vc -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-kcs,bmc=bmc0,ioport=0xca2 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffec4268700 (LWP 7657)] __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757 (gdb) bt #0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757 #1 0x00005555559ef775 in memcpy (__len=3, __src=0xc1421c, __dest=<optimized out>) at /usr/include/bits/string3.h:51 #2 qemu_put_buffer (f=0x555557a97690, buf=0xc1421c <Address 0xc1421c out of bounds>, size=3) at migration/qemu-file.c:346 qemu#3 0x00005555559eef66 in vmstate_save_state (f=f@entry=0x555557a97690, vmsd=0x555555f8a5a0 <vmstate_ISAIPMIKCSDevice>, opaque=0x555557231160, vmdesc=vmdesc@entry=0x55555798cc40) at migration/vmstate.c:333 qemu#4 0x00005555557cfe45 in vmstate_save (f=f@entry=0x555557a97690, se=se@entry=0x555557231de0, vmdesc=vmdesc@entry=0x55555798cc40) at /mnt/sdb/zyy/qemu/migration/savevm.c:720 qemu#5 0x00005555557d2be7 in qemu_savevm_state_complete_precopy (f=0x555557a97690, iterable_only=iterable_only@entry=false) at /mnt/sdb/zyy/qemu/migration/savevm.c:1128 qemu#6 0x00005555559ea102 in migration_completion (start_time=<synthetic pointer>, old_vm_running=<synthetic pointer>, current_active_state=<optimized out>, s=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1707 qemu#7 migration_thread (opaque=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1855 qemu#8 0x00007ffff3900dc5 in start_thread (arg=0x7ffec4268700) at pthread_create.c:308 qemu#9 0x00007fffefc6c71d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Current code that handles Tx buffer desciprtor ring scanning employs the following algorithm: 1. Restore current buffer descriptor pointer from TBPTRn 2. Process current descriptor 3. If current descriptor has BD_WRAP flag set set current descriptor pointer to start of the descriptor ring 4. If current descriptor points to start of the ring exit the loop, otherwise increment current descriptor pointer and go to #2 5. Store current descriptor in TBPTRn The way the code is implemented results in buffer descriptor ring being scanned starting at offset/descriptor #0. While covering 99% of the cases, this algorithm becomes problematic for a number of edge cases. Consider the following scenario: guest OS driver initializes descriptor ring to N individual descriptors and starts sending data out. Depending on the volume of traffic and probably guest OS driver implementation it is possible that an edge case where a packet, spread across 2 descriptors is placed in descriptors N - 1 and 0 in that order(it is easy to imagine similar examples involving more than 2 descriptors). What happens then is aforementioned algorithm starts at descriptor 0, sees a descriptor marked as BD_LAST, which it happily sends out as a separate packet(very much malformed at this point) then the iteration continues and the first part of the original packet is tacked to the next transmission which ends up being bogus as well. This behvaiour can be pretty reliably observed when scp'ing data from a guest OS via TAP interface for files larger than 160K (every time for 700K+). This patch changes the scanning algorithm to do the following: 1. Restore "current" buffer descriptor pointer from TBPTRn 2. If "current" descriptor does not have BD_TX_READY set, goto qemu#6 3. Process current descriptor 4. If "current" descriptor has BD_WRAP flag set "current" descriptor pointer to start of the descriptor ring otherwise set increment "current" by the size of one descriptor 5. Goto #1 6. Save "current" buffer descriptor in TBPTRn This way we preserve the information about which descriptor was processed last and always start where we left off avoiding the original problem. On top of that, judging by the following excerpt from MPC8548ERM (p. 14-48): "... When the end of the TxBD ring is reached, eTSEC initializes TBPTRn to the value in the corresponding TBASEn. The TBPTR register is internally written by the eTSEC’s DMA controller during transmission. The pointer increments by eight (bytes) each time a descriptor is closed successfully by the eTSEC..." revised algorithm might also a more correct way of emulating this aspect of eTSEC peripheral. Cc: Alexander Graf <agraf@suse.de> Cc: Scott Wood <scottwood@freescale.com> Cc: Jason Wang <jasowang@redhat.com> Cc: qemu-devel@nongnu.org Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com>

QEMU will crash with the follow backtrace if the new created thread exited before we call qemu_thread_set_name() for it. (gdb) bt #0 0x00007f9a68b095d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f9a68b0acc8 in __GI_abort () at abort.c:90 #2 0x00007f9a69cda389 in PAT_abort () from /usr/lib64/libuvpuserhotfix.so qemu#3 0x00007f9a69cdda0d in patchIllInsHandler () from /usr/lib64/libuvpuserhotfix.so qemu#4 <signal handler called> qemu#5 pthread_setname_np (th=140298470549248, name=name@entry=0x8cc74a "io-task-worker") at ../nptl/sysdeps/unix/sysv/linux/pthread_setname.c:49 qemu#6 0x00000000007f5f20 in qemu_thread_set_name (thread=thread@entry=0x7ffd2ac09680, name=name@entry=0x8cc74a "io-task-worker") at util/qemu_thread_posix.c:459 qemu#7 0x00000000007f679e in qemu_thread_create (thread=thread@entry=0x7ffd2ac09680, name=name@entry=0x8cc74a "io-task-worker",start_routine=start_routine@entry=0x7c1300 <qio_task_thread_worker>, arg=arg@entry=0x7f99b8001720, mode=mode@entry=1) at util/qemu_thread_posix.c:498 qemu#8 0x00000000007c15b6 in qio_task_run_in_thread (task=task@entry=0x7f99b80033d0, worker=worker@entry=0x7bd920 <qio_channel_socket_connect_worker>, opaque=0x7f99b8003370, destroy=0x7c6220 <qapi_free_SocketAddress>) at io/task.c:133 qemu#9 0x00000000007bda04 in qio_channel_socket_connect_async (ioc=0x7f99b80014c0, addr=0x37235d0, callback=callback@entry=0x54ad00 <qemu_chr_socket_connected>, opaque=opaque@entry=0x38118b0, destroy=destroy@entry=0x0) at io/channel_socket.c:191 qemu#10 0x00000000005487f6 in socket_reconnect_timeout (opaque=0x38118b0) at qemu_char.c:4402 qemu#11 0x00007f9a6a1533b3 in g_timeout_dispatch () from /usr/lib64/libglib-2.0.so.0 qemu#12 0x00007f9a6a15299a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 qemu#13 0x0000000000747386 in glib_pollfds_poll () at main_loop.c:227 qemu#14 0x0000000000747424 in os_host_main_loop_wait (timeout=404000000) at main_loop.c:272 qemu#15 0x0000000000747575 in main_loop_wait (nonblocking=nonblocking@entry=0) at main_loop.c:520 qemu#16 0x0000000000557d31 in main_loop () at vl.c:2170 qemu#17 0x000000000041c8b7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:5083 Let's detach the new thread after calling qemu_thread_set_name(). Signed-off-by: Caoxinhua <caoxinhua@huawei.com> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com> Message-Id: <1483493521-9604-1-git-send-email-zhang.zhanghailiang@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

AioHandlers marked ->is_external must be skipped when aio_node_check() fails. bdrv_drained_begin() needs this to prevent dataplane from submitting new I/O requests while another thread accesses the device and relies on it being quiesced. This patch fixes the following segfault: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00005577f6127dad in bdrv_io_plug (bs=0x5577f7ae52f0) at qemu/block/io.c:2650 2650 bdrv_io_plug(child->bs); [Current thread is 1 (Thread 0x7ff5c4bd1c80 (LWP 10917))] (gdb) bt #0 0x00005577f6127dad in bdrv_io_plug (bs=0x5577f7ae52f0) at qemu/block/io.c:2650 #1 0x00005577f6114363 in blk_io_plug (blk=0x5577f7b8ba20) at qemu/block/block-backend.c:1561 #2 0x00005577f5d4091d in virtio_blk_handle_vq (s=0x5577f9ada030, vq=0x5577f9b3d2a0) at qemu/hw/block/virtio-blk.c:589 qemu#3 0x00005577f5d4240d in virtio_blk_data_plane_handle_output (vdev=0x5577f9ada030, vq=0x5577f9b3d2a0) at qemu/hw/block/dataplane/virtio-blk.c:158 qemu#4 0x00005577f5d88acd in virtio_queue_notify_aio_vq (vq=0x5577f9b3d2a0) at qemu/hw/virtio/virtio.c:1304 qemu#5 0x00005577f5d8aaaf in virtio_queue_host_notifier_aio_poll (opaque=0x5577f9b3d308) at qemu/hw/virtio/virtio.c:2134 qemu#6 0x00005577f60ca077 in run_poll_handlers_once (ctx=0x5577f79ddbb0) at qemu/aio-posix.c:493 qemu#7 0x00005577f60ca268 in try_poll_mode (ctx=0x5577f79ddbb0, blocking=true) at qemu/aio-posix.c:569 qemu#8 0x00005577f60ca331 in aio_poll (ctx=0x5577f79ddbb0, blocking=true) at qemu/aio-posix.c:601 qemu#9 0x00005577f612722a in bdrv_flush (bs=0x5577f7c20970) at qemu/block/io.c:2403 qemu#10 0x00005577f60c1b2d in bdrv_close (bs=0x5577f7c20970) at qemu/block.c:2322 qemu#11 0x00005577f60c20e7 in bdrv_delete (bs=0x5577f7c20970) at qemu/block.c:2465 qemu#12 0x00005577f60c3ecf in bdrv_unref (bs=0x5577f7c20970) at qemu/block.c:3425 qemu#13 0x00005577f60bf951 in bdrv_root_unref_child (child=0x5577f7a2de70) at qemu/block.c:1361 qemu#14 0x00005577f6112162 in blk_remove_bs (blk=0x5577f7b8ba20) at qemu/block/block-backend.c:491 qemu#15 0x00005577f6111b1b in blk_remove_all_bs () at qemu/block/block-backend.c:245 qemu#16 0x00005577f60c1db6 in bdrv_close_all () at qemu/block.c:2382 qemu#17 0x00005577f5e60cca in main (argc=20, argv=0x7ffea6eb8398, envp=0x7ffea6eb8440) at qemu/vl.c:4684 The key thing is that bdrv_close() uses bdrv_drained_begin() and virtio_queue_host_notifier_aio_poll() must not be called. Thanks to Fam Zheng <famz@redhat.com> for identifying the root cause of this crash. Reported-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Tested-by: Alberto Garcia <berto@igalia.com> Message-id: 20170124095350.16679-1-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Running postcopy-test with ASAN produces the following error: QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/postcopy-test ... ================================================================= ==23641==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f1556600000 at pc 0x55b8e9d28208 bp 0x7f1555f4d3c0 sp 0x7f1555f4d3b0 READ of size 8 at 0x7f1556600000 thread T6 #0 0x55b8e9d28207 in htab_save_first_pass /home/elmarco/src/qq/hw/ppc/spapr.c:1528 #1 0x55b8e9d2939c in htab_save_iterate /home/elmarco/src/qq/hw/ppc/spapr.c:1665 #2 0x55b8e9beae3a in qemu_savevm_state_iterate /home/elmarco/src/qq/migration/savevm.c:1044 qemu#3 0x55b8ea677733 in migration_thread /home/elmarco/src/qq/migration/migration.c:1976 qemu#4 0x7f15845f46c9 in start_thread (/lib64/libpthread.so.0+0x76c9) qemu#5 0x7f157d9d0f7e in clone (/lib64/libc.so.6+0x107f7e) 0x7f1556600000 is located 0 bytes to the right of 2097152-byte region [0x7f1556400000,0x7f1556600000) allocated by thread T0 here: #0 0x7f159bb76980 in posix_memalign (/lib64/libasan.so.3+0xc7980) #1 0x55b8eab185b2 in qemu_try_memalign /home/elmarco/src/qq/util/oslib-posix.c:106 #2 0x55b8eab186c8 in qemu_memalign /home/elmarco/src/qq/util/oslib-posix.c:122 qemu#3 0x55b8e9d268a8 in spapr_reallocate_hpt /home/elmarco/src/qq/hw/ppc/spapr.c:1214 qemu#4 0x55b8e9d26e04 in ppc_spapr_reset /home/elmarco/src/qq/hw/ppc/spapr.c:1261 qemu#5 0x55b8ea12e913 in qemu_system_reset /home/elmarco/src/qq/vl.c:1697 qemu#6 0x55b8ea13fa40 in main /home/elmarco/src/qq/vl.c:4679 qemu#7 0x7f157d8e9400 in __libc_start_main (/lib64/libc.so.6+0x20400) Thread T6 created by T0 here: #0 0x7f159bae0488 in __interceptor_pthread_create (/lib64/libasan.so.3+0x31488) #1 0x55b8eab1d9cb in qemu_thread_create /home/elmarco/src/qq/util/qemu-thread-posix.c:465 #2 0x55b8ea67874c in migrate_fd_connect /home/elmarco/src/qq/migration/migration.c:2096 qemu#3 0x55b8ea66cbb0 in migration_channel_connect /home/elmarco/src/qq/migration/migration.c:500 qemu#4 0x55b8ea678f38 in socket_outgoing_migration /home/elmarco/src/qq/migration/socket.c:87 qemu#5 0x55b8eaa5a03a in qio_task_complete /home/elmarco/src/qq/io/task.c:142 qemu#6 0x55b8eaa599cc in gio_task_thread_result /home/elmarco/src/qq/io/task.c:88 qemu#7 0x7f15823e38e6 (/lib64/libglib-2.0.so.0+0x468e6) SUMMARY: AddressSanitizer: heap-buffer-overflow /home/elmarco/src/qq/hw/ppc/spapr.c:1528 in htab_save_first_pass index seems to be wrongly incremented, unless I miss something that would be worth a comment. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

During block job completion, nothing is preventing block_job_defer_to_main_loop_bh from being called in a nested aio_poll(), which is a trouble, such as in this code path: qmp_block_commit commit_active_start bdrv_reopen bdrv_reopen_multiple bdrv_reopen_prepare bdrv_flush aio_poll aio_bh_poll aio_bh_call block_job_defer_to_main_loop_bh stream_complete bdrv_reopen block_job_defer_to_main_loop_bh is the last step of the stream job, which should have been "paused" by the bdrv_drained_begin/end in bdrv_reopen_multiple, but it is not done because it's in the form of a main loop BH. Similar to why block jobs should be paused between drained_begin and drained_end, BHs they schedule must be excluded as well. To achieve this, this patch forces draining the BH in BDRV_POLL_WHILE. As a side effect this fixes a hang in block_job_detach_aio_context during system_reset when a block job is ready: #0 0x0000555555aa79f3 in bdrv_drain_recurse #1 0x0000555555aa825d in bdrv_drained_begin #2 0x0000555555aa8449 in bdrv_drain qemu#3 0x0000555555a9c356 in blk_drain qemu#4 0x0000555555aa3cfd in mirror_drain qemu#5 0x0000555555a66e11 in block_job_detach_aio_context qemu#6 0x0000555555a62f4d in bdrv_detach_aio_context qemu#7 0x0000555555a63116 in bdrv_set_aio_context qemu#8 0x0000555555a9d326 in blk_set_aio_context qemu#9 0x00005555557e38da in virtio_blk_data_plane_stop qemu#10 0x00005555559f9d5f in virtio_bus_stop_ioeventfd qemu#11 0x00005555559fa49b in virtio_bus_stop_ioeventfd qemu#12 0x00005555559f6a18 in virtio_pci_stop_ioeventfd qemu#13 0x00005555559f6a18 in virtio_pci_reset qemu#14 0x00005555559139a9 in qdev_reset_one qemu#15 0x0000555555916738 in qbus_walk_children qemu#16 0x0000555555913318 in qdev_walk_children qemu#17 0x0000555555916738 in qbus_walk_children qemu#18 0x00005555559168ca in qemu_devices_reset qemu#19 0x000055555581fcbb in pc_machine_reset qemu#20 0x00005555558a4d96 in qemu_system_reset qemu#21 0x000055555577157a in main_loop_should_exit qemu#22 0x000055555577157a in main_loop qemu#23 0x000055555577157a in main The rationale is that the loop in block_job_detach_aio_context cannot make any progress in pausing/completing the job, because bs->in_flight is 0, so bdrv_drain doesn't process the block_job_defer_to_main_loop BH. With this patch, it does. Reported-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Message-Id: <20170418143044.12187-3-famz@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Tested-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>

ASAN detects an "unknown-crash" when running pxe-test: /ppc64/pxe/spapr-vlan: ================================================================= ==7143==ERROR: AddressSanitizer: unknown-crash on address 0x7f6dcd298d30 at pc 0x55e22218830d bp 0x7f6dcd2989e0 sp 0x7f6dcd2989d0 READ of size 128 at 0x7f6dcd298d30 thread T2 #0 0x55e22218830c in tftp_session_allocate /home/elmarco/src/qq/slirp/tftp.c:73 #1 0x55e22218a1f8 in tftp_handle_rrq /home/elmarco/src/qq/slirp/tftp.c:289 #2 0x55e22218b54c in tftp_input /home/elmarco/src/qq/slirp/tftp.c:446 qemu#3 0x55e2221833fe in udp6_input /home/elmarco/src/qq/slirp/udp6.c:82 qemu#4 0x55e222137b17 in ip6_input /home/elmarco/src/qq/slirp/ip6_input.c:67 Address 0x7f6dcd298d30 is located in stack of thread T2 at offset 96 in frame #0 0x55e222182420 in udp6_input /home/elmarco/src/qq/slirp/udp6.c:13 This frame has 3 object(s): [32, 48) '<unknown>' [96, 124) 'lhost' <== Memory access at offset 96 partially overflows this variable [160, 200) 'save_ip' <== Memory access at offset 96 partially underflows this variable The sockaddr_storage pointer is the sockaddr_in6 lhost on the stack. Copy only the source addr size. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

If trace backend is set to TRACE_NOP, trace_get_vcpu_event_count returns 0, cause bitmap_new call abort. The abort can be triggered as follows: $ ./configure --enable-trace-backend=nop --target-list=x86_64-softmmu $ gdb ./x86_64-softmmu/qemu-system-x86_64 -M q35,accel=kvm -m 1G (gdb) bt #0 0x00007ffff04e25f7 in raise () from /lib64/libc.so.6 #1 0x00007ffff04e3ce8 in abort () from /lib64/libc.so.6 #2 0x00005555559de905 in bitmap_new (nbits=<optimized out>) at /home/root/git/qemu2.git/include/qemu/bitmap.h:96 qemu#3 cpu_common_initfn (obj=0x555556621d30) at qom/cpu.c:399 qemu#4 0x0000555555a11869 in object_init_with_type (obj=0x555556621d30, ti=0x55555656bbb0) at qom/object.c:341 qemu#5 0x0000555555a11869 in object_init_with_type (obj=0x555556621d30, ti=0x55555656bd30) at qom/object.c:341 qemu#6 0x0000555555a11efc in object_initialize_with_type (data=data@entry=0x555556621d30, size=76560, type=type@entry=0x55555656bd30) at qom/object.c:376 qemu#7 0x0000555555a12061 in object_new_with_type (type=0x55555656bd30) at qom/object.c:484 qemu#8 0x0000555555a121c5 in object_new (typename=typename@entry=0x555556550340 "qemu64-x86_64-cpu") at qom/object.c:494 qemu#9 0x00005555557f6e3d in pc_new_cpu (typename=typename@entry=0x555556550340 "qemu64-x86_64-cpu", apic_id=0, errp=errp@entry=0x5555565391b0 <error_fatal>) at /home/root/git/qemu2.git/hw/i386/pc.c:1101 qemu#10 0x00005555557fa33e in pc_cpus_init (pcms=pcms@entry=0x5555565f9690) at /home/root/git/qemu2.git/hw/i386/pc.c:1184 qemu#11 0x00005555557fe0f6 in pc_q35_init (machine=0x5555565f9690) at /home/root/git/qemu2.git/hw/i386/pc_q35.c:121 qemu#12 0x000055555574fbad in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4562 Signed-off-by: Anthony Xu <anthony.xu@intel.com> Message-id: 1494369432-15418-1-git-send-email-anthony.xu@intel.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Spotted by ASAN: /x86_64/hmp/pc-0.12: ================================================================= ==22538==ERROR: LeakSanitizer: detected memory leaks Direct leak of 224 byte(s) in 1 object(s) allocated from: #0 0x7f0f63cdee60 in malloc (/lib64/libasan.so.3+0xc6e60) #1 0x556f11ff32d7 in tcp_newtcpcb /home/elmarco/src/qemu/slirp/tcp_subr.c:250 #2 0x556f11fdb1d1 in tcp_listen /home/elmarco/src/qemu/slirp/socket.c:688 qemu#3 0x556f11fca9d5 in slirp_add_hostfwd /home/elmarco/src/qemu/slirp/slirp.c:1052 qemu#4 0x556f11f8db41 in slirp_hostfwd /home/elmarco/src/qemu/net/slirp.c:506 qemu#5 0x556f11f8dd83 in hmp_hostfwd_add /home/elmarco/src/qemu/net/slirp.c:535 There might be a better way to fix this, but calling slirp tcp_close() doesn't work. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

Since commit d4c19cd ("virtio-serial: add missing virtio_detach_element() call") the following commands may cause QEMU to segfault: $ qemu -M accel=kvm -cpu host -m 1G \ -drive if=virtio,file=test.img,format=raw \ -device virtio-serial-pci,id=virtio-serial0 \ -chardev socket,id=channel1,path=/tmp/chardev.sock,server,nowait \ -device virtserialport,chardev=channel1,bus=virtio-serial0.0,id=port1 $ nc -U /tmp/chardev.sock ^C (guest)$ cat /dev/zero >/dev/vport0p1 The segfault is non-deterministic: if the event loop notices the socket has been closed then there is no crash. The disconnect has to happen right before QEMU attempts to write data to the socket. The backtrace is as follows: Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x00005555557e0698 in do_flush_queued_data (port=0x5555582cedf0, vq=0x7fffcc854290, vdev=0x55555807b1d0) at hw/char/virtio-serial-bus.c:180 180 for (i = port->iov_idx; i < port->elem->out_num; i++) { #1 0x000055555580d363 in virtio_queue_notify_vq (vq=0x7fffcc854290) at hw/virtio/virtio.c:1524 #2 0x000055555580d363 in virtio_queue_host_notifier_read (n=0x7fffcc8542f8) at hw/virtio/virtio.c:2430 qemu#3 0x0000555555b3482c in aio_dispatch_handlers (ctx=ctx@entry=0x5555566b8c80) at util/aio-posix.c:399 qemu#4 0x0000555555b350d8 in aio_dispatch (ctx=0x5555566b8c80) at util/aio-posix.c:430 qemu#5 0x0000555555b3212e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:261 qemu#6 0x00007fffde71de52 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 qemu#7 0x0000555555b34353 in glib_pollfds_poll () at util/main-loop.c:213 qemu#8 0x0000555555b34353 in os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261 qemu#9 0x0000555555b34353 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:517 qemu#10 0x0000555555773207 in main_loop () at vl.c:1917 qemu#11 0x0000555555773207 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4751 The do_flush_queued_data() function does not anticipate chardev close events during vsc->have_data(). It expects port->elem to remain non-NULL for the duration its for loop. The fix is simply to return from do_flush_queued_data() if the port closes because the close event already frees port->elem and drains the virtqueue - there is nothing left for do_flush_queued_data() to do. Reported-by: Sitong Liu <siliu@redhat.com> Reported-by: Min Deng <mdeng@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

…ered Submission of requests on linux aio is a bit tricky and can lead to requests completions on submission path: 44713c9 ("linux-aio: Handle io_submit() failure gracefully") 0ed93d8 ("linux-aio: process completions from ioq_submit()") That means that any coroutine which has been yielded in order to wait for completion can be resumed from submission path and be eventually terminated (freed). The following use-after-free crash was observed when IO throttling was enabled: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f5813dff700 (LWP 56417)] virtqueue_unmap_sg (elem=0x7f5804009a30, len=1, vq=<optimized out>) at virtio.c:252 (gdb) bt #0 virtqueue_unmap_sg (elem=0x7f5804009a30, len=1, vq=<optimized out>) at virtio.c:252 ^^^^^^^^^^^^^^ remember the address #1 virtqueue_fill (vq=0x5598b20d21b0, elem=0x7f5804009a30, len=1, idx=0) at virtio.c:282 #2 virtqueue_push (vq=0x5598b20d21b0, elem=elem@entry=0x7f5804009a30, len=<optimized out>) at virtio.c:308 qemu#3 virtio_blk_req_complete (req=req@entry=0x7f5804009a30, status=status@entry=0 '\000') at virtio-blk.c:61 qemu#4 virtio_blk_rw_complete (opaque=<optimized out>, ret=0) at virtio-blk.c:126 qemu#5 blk_aio_complete (acb=0x7f58040068d0) at block-backend.c:923 qemu#6 coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at coroutine-ucontext.c:78 (gdb) p * elem $8 = {index = 77, out_num = 2, in_num = 1, in_addr = 0x7f5804009ad8, out_addr = 0x7f5804009ae0, in_sg = 0x0, out_sg = 0x7f5804009a50} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 'in_sg' and 'out_sg' are invalid. e.g. it is impossible that 'in_sg' is zero, instead its value must be equal to: (gdb) p/x 0x7f5804009ad8 + sizeof(elem->in_addr[0]) + 2 * sizeof(elem->out_addr[0]) $26 = 0x7f5804009af0 Seems 'elem' was corrupted. Meanwhile another thread raised an abort: Thread 12 (Thread 0x7f57f2ffd700 (LWP 56426)): #0 raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 qemu_coroutine_enter (co=0x7f5804009af0) at qemu-coroutine.c:113 qemu#3 qemu_co_queue_run_restart (co=0x7f5804009a30) at qemu-coroutine-lock.c:60 qemu#4 qemu_coroutine_enter (co=0x7f5804009a30) at qemu-coroutine.c:119 ^^^^^^^^^^^^^^^^^^ WTF?? this is equal to elem from crashed thread qemu#5 qemu_co_queue_run_restart (co=0x7f57e7f16ae0) at qemu-coroutine-lock.c:60 qemu#6 qemu_coroutine_enter (co=0x7f57e7f16ae0) at qemu-coroutine.c:119 qemu#7 qemu_co_queue_run_restart (co=0x7f5807e112a0) at qemu-coroutine-lock.c:60 qemu#8 qemu_coroutine_enter (co=0x7f5807e112a0) at qemu-coroutine.c:119 qemu#9 qemu_co_queue_run_restart (co=0x7f5807f17820) at qemu-coroutine-lock.c:60 qemu#10 qemu_coroutine_enter (co=0x7f5807f17820) at qemu-coroutine.c:119 qemu#11 qemu_co_queue_run_restart (co=0x7f57e7f18e10) at qemu-coroutine-lock.c:60 qemu#12 qemu_coroutine_enter (co=0x7f57e7f18e10) at qemu-coroutine.c:119 qemu#13 qemu_co_enter_next (queue=queue@entry=0x5598b1e742d0) at qemu-coroutine-lock.c:106 qemu#14 timer_cb (blk=0x5598b1e74280, is_write=<optimized out>) at throttle-groups.c:419 Crash can be explained by access of 'co' object from the loop inside qemu_co_queue_run_restart(): while ((next = QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); ^^^^^^^^^^^^^^^^^^^^ on each iteration 'co' is accessed, but 'co' can be already freed qemu_coroutine_enter(next); } When 'next' coroutine is resumed (entered) it can in its turn resume 'co', and eventually free it. That's why we see 'co' (which was freed) has the same address as 'elem' from the first backtrace. The fix is obvious: use temporary queue and do not touch coroutine after first qemu_coroutine_enter() is invoked. The issue is quite rare and happens every ~12 hours on very high IO and CPU load (building linux kernel with -j512 inside guest) when IO throttling is enabled. With the fix applied guest is running ~35 hours and is still alive so far. Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20170601160847.23720-1-roman.penyaev@profitbricks.com Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Fam Zheng <famz@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Cc: qemu-devel@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

V flag for subtraction is: v = (res ^ src1) & (src1 ^ src2) (see COMPUTE_CCR() in target/m68k/helper.c) But gen_flush_flags() uses: v = (res ^ src2) & (src1 ^ src2) The problem has been found with the following program: .global _start _start: move.l #-2147483648,%d0 subq.l #1,%d0 jvc 1f move.l #1,%d1 move.l #1,%d0 trap #0 1: move.l #0,%d1 move.l #1,%d0 trap #0 It works fine (exit(1)) on real hardware, and with "-singlestep". "-singlestep" uses gen_helper_flush_flags(), whereas without "-singlestep", V flag is computed directly in gen_flush_flags(). This patch updates gen_flush_flags() to have the same result as with gen_helper_flush_flags(). Signed-off-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Richard Henderson <rth@twiddle.net> Message-Id: <20170614203905.19657-1-laurent@vivier.eu>

Commit e987c37 ("hw/i386: check if nvdimm is enabled before plugging") introduced a check to reject nvdimm hotplug if -machine pc,nvdimm=on was not given. This check executes after pc_dimm_memory_plug() has already completed and does not reverse the effect of this function in the case of failure. Perform the check before calling pc_dimm_memory_plug(). This fixes the following abort: $ qemu -M accel=kvm -m 1G,slots=4,maxmem=8G \ -object memory-backend-file,id=mem1,share=on,mem-path=nvdimm.dat,size=1G (qemu) device_add nvdimm,memdev=mem1 nvdimm is not enabled: missing 'nvdimm' in '-M' (qemu) device_add nvdimm,memdev=mem1 Core dumped The backtrace is: #0 0x00007fffdb5b191f in raise () at /lib64/libc.so.6 #1 0x00007fffdb5b351a in abort () at /lib64/libc.so.6 #2 0x00007fffdb5a9da7 in __assert_fail_base () at /lib64/libc.so.6 qemu#3 0x00007fffdb5a9e52 in () at /lib64/libc.so.6 qemu#4 0x000055555577a5fa in qemu_ram_set_idstr (new_block=0x555556747a00, name=<optimized out>, dev=dev@entry=0x555556705590) at qemu/exec.c:1709 qemu#5 0x0000555555a0fe86 in vmstate_register_ram (mr=mr@entry=0x55555673a0e0, dev=dev@entry=0x555556705590) at migration/savevm.c:2293 qemu#6 0x0000555555965088 in pc_dimm_memory_plug (dev=dev@entry=0x555556705590, hpms=hpms@entry=0x5555566bb0e0, mr=mr@entry=0x555556705630, align=<optimized out>, errp=errp@entry=0x7fffffffc660) at hw/mem/pc-dimm.c:110 qemu#7 0x000055555581d89b in pc_dimm_plug (errp=0x7fffffffc6c0, dev=0x555556705590, hotplug_dev=<optimized out>) at qemu/hw/i386/pc.c:1713 qemu#8 0x000055555581d89b in pc_machine_device_plug_cb (hotplug_dev=<optimized out>, dev=0x555556705590, errp=0x7fffffffc6c0) at qemu/hw/i386/pc.c:2004 qemu#9 0x0000555555914da6 in device_set_realized (obj=<optimized out>, value=<optimized out>, errp=0x7fffffffc7e8) at hw/core/qdev.c:926 Cc: Haozhong Zhang <haozhong.zhang@intel.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

"nc" is freed after hotplug vhost-user, but the watcher is not removed. The QEMU crash when the watcher access the "nc" when socket disconnects. Program received signal SIGSEGV, Segmentation fault. #0 object_get_class (obj=obj@entry=0x2) at qom/object.c:750 #1 0x00007f9bb4180da1 in qemu_chr_fe_disconnect (be=<optimized out>) at chardev/char-fe.c:372 #2 0x00007f9bb40d1100 in net_vhost_user_watch (chan=<optimized out>, cond=<optimized out>, opaque=<optimized out>) at net/vhost-user.c:188 qemu#3 0x00007f9baf97f99a in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 qemu#4 0x00007f9bb41d7ebc in glib_pollfds_poll () at util/main-loop.c:213 qemu#5 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261 qemu#6 main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:515 qemu#7 0x00007f9bb3e266a7 in main_loop () at vl.c:1917 qemu#8 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4786 Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

The following segfault is encountered if the NBD server closes the UNIX domain socket immediately after negotiation: Program terminated with signal SIGSEGV, Segmentation fault. #0 aio_co_schedule (ctx=0x0, co=0xd3c0ff2ef0) at util/async.c:441 441 QSLIST_INSERT_HEAD_ATOMIC(&ctx->scheduled_coroutines, (gdb) bt #0 0x000000d3c01a50f8 in aio_co_schedule (ctx=0x0, co=0xd3c0ff2ef0) at util/async.c:441 #1 0x000000d3c012fa90 in nbd_coroutine_end (bs=bs@entry=0xd3c0fec650, request=<optimized out>) at block/nbd-client.c:207 #2 0x000000d3c012fb58 in nbd_client_co_preadv (bs=0xd3c0fec650, offset=0, bytes=<optimized out>, qiov=0x7ffc10a91b20, flags=0) at block/nbd-client.c:237 qemu#3 0x000000d3c0128e63 in bdrv_driver_preadv (bs=bs@entry=0xd3c0fec650, offset=offset@entry=0, bytes=bytes@entry=512, qiov=qiov@entry=0x7ffc10a91b20, flags=0) at block/io.c:836 qemu#4 0x000000d3c012c3e0 in bdrv_aligned_preadv (child=child@entry=0xd3c0ff51d0, req=req@entry=0x7f31885d6e90, offset=offset@entry=0, bytes=bytes@entry=512, align=align@entry=1, qiov=qiov@entry=0x7ffc10a91b20, f +lags=0) at block/io.c:1086 qemu#5 0x000000d3c012c6b8 in bdrv_co_preadv (child=0xd3c0ff51d0, offset=offset@entry=0, bytes=bytes@entry=512, qiov=qiov@entry=0x7ffc10a91b20, flags=flags@entry=0) at block/io.c:1182 qemu#6 0x000000d3c011cc17 in blk_co_preadv (blk=0xd3c0ff4f80, offset=0, bytes=512, qiov=0x7ffc10a91b20, flags=0) at block/block-backend.c:1032 qemu#7 0x000000d3c011ccec in blk_read_entry (opaque=0x7ffc10a91b40) at block/block-backend.c:1079 qemu#8 0x000000d3c01bbb96 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:79 qemu#9 0x00007f3196cb8600 in __start_context () at /lib64/libc.so.6 The problem is that nbd_client_init() uses nbd_client_attach_aio_context() -> aio_co_schedule(new_context, client->read_reply_co). Execution of read_reply_co is deferred to a BH which doesn't run until later. In the mean time blk_co_preadv() can be called and nbd_coroutine_end() calls aio_wake() on read_reply_co. At this point in time read_reply_co's ctx isn't set because it has never been entered yet. This patch simplifies the nbd_co_send_request() -> nbd_co_receive_reply() -> nbd_coroutine_end() lifecycle to just nbd_co_send_request() -> nbd_co_receive_reply(). The request is "ended" if an error occurs at any point. Callers no longer have to invoke nbd_coroutine_end(). This cleanup also eliminates the segfault because we don't call aio_co_schedule() to wake up s->read_reply_co if sending the request failed. It is only necessary to wake up s->read_reply_co if a reply was received. Note this only happens with UNIX domain sockets on Linux. It doesn't seem possible to reproduce this with TCP sockets. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20170829122745.14309-2-stefanha@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>

currently for sh4 cpu_model argument for '-cpu' option could be either 'cpu model' name or cpu_typename. however typically '-cpu' takes 'cpu model' name and cpu type for sh4 target isn't advertised publicly ('-cpu help' prints only 'cpu model' names) so we shouldn't care about this use case (it's more of a bug). 1. Drop '-cpu cpu_typename' to align with the rest of targets. 2. Compose searched for typename from cpu model and use it with object_class_by_name() directly instead of over-complicated object_class_get_list() g_slist_find_custom() + superh_cpu_name_compare() With #1 droped, #2 could be used for both lookups which simplifies superh_cpu_class_by_name() quite a bit. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1507211474-188400-23-git-send-email-imammedo@redhat.com> [ehabkost: Include fixup sent by Igor] Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

Since commit 6f5fd83, vu_init() can fail if malloc() returns NULL. This fixes the following Coverity warning: CID 1435958 (#1 of 1): Unchecked return value (CHECKED_RETURN) Fixes: 6f5fd83 ("libvhost-user: support many virtqueues") Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20201102092339.2034297-1-philmd@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

mon_get_cpu_env() is indirectly called monitor_parse_arguments() where the current monitor isn't set yet. Instead of using monitor_cur_env(), explicitly pass the Monitor pointer to the function. Without this fix, an HMP command like "x $pc" crashes like this: #0 0x0000555555caa01f in mon_get_cpu_sync (mon=0x0, synchronize=true) at ../monitor/misc.c:270 #1 0x0000555555caa141 in mon_get_cpu (mon=0x0) at ../monitor/misc.c:294 #2 0x0000555555caa158 in mon_get_cpu_env () at ../monitor/misc.c:299 qemu#3 0x0000555555b19739 in monitor_get_pc (mon=0x555556ad2de0, md=0x5555565d2d40 <monitor_defs+1152>, val=0) at ../target/i386/monitor.c:607 qemu#4 0x0000555555cadbec in get_monitor_def (mon=0x555556ad2de0, pval=0x7fffffffc208, name=0x7fffffffc220 "pc") at ../monitor/misc.c:1681 qemu#5 0x000055555582ec4f in expr_unary (mon=0x555556ad2de0) at ../monitor/hmp.c:387 qemu#6 0x000055555582edbb in expr_prod (mon=0x555556ad2de0) at ../monitor/hmp.c:421 qemu#7 0x000055555582ee79 in expr_logic (mon=0x555556ad2de0) at ../monitor/hmp.c:455 qemu#8 0x000055555582eefe in expr_sum (mon=0x555556ad2de0) at ../monitor/hmp.c:484 qemu#9 0x000055555582efe8 in get_expr (mon=0x555556ad2de0, pval=0x7fffffffc418, pp=0x7fffffffc408) at ../monitor/hmp.c:511 qemu#10 0x000055555582fcd4 in monitor_parse_arguments (mon=0x555556ad2de0, endp=0x7fffffffc890, cmd=0x555556675b50 <hmp_cmds+7920>) at ../monitor/hmp.c:876 qemu#11 0x00005555558306a8 in handle_hmp_command (mon=0x555556ad2de0, cmdline=0x555556ada452 "$pc") at ../monitor/hmp.c:1087 qemu#12 0x000055555582df14 in monitor_command_cb (opaque=0x555556ad2de0, cmdline=0x555556ada450 "x $pc", readline_opaque=0x0) at ../monitor/hmp.c:47 After this fix, nothing is left in monitor_parse_arguments() that can indirectly call monitor_cur(), so the fix is complete. Fixes: ff04108 Reported-by: lichun <lichun@ruijie.com.cn> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201113114326.97663-4-kwolf@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

In qobject_type(), NULL is returned when the 'QObject' returned from parse_value() is not of QString type, and this 'QObject' memory will leaked. So we need to first cache the 'QObject' returned from parse_value(), and finally free 'QObject' memory at the end of the function. Also, we add a testcast about invalid dict key. The memleak stack is as follows: Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0xfffe4b3c34fb in __interceptor_malloc (/lib64/libasan.so.4+0xd34fb) #1 0xfffe4ae48aa3 in g_malloc (/lib64/libglib-2.0.so.0+0x58aa3) #2 0xaaab3557d9f7 in qnum_from_int qemu/qobject/qnum.c:25 qemu#3 0xaaab35584d23 in parse_literal qemu/qobject/json-parser.c:511 qemu#4 0xaaab35584d23 in parse_value qemu/qobject/json-parser.c:554 qemu#5 0xaaab35583d77 in parse_pair qemu/qobject/json-parser.c:270 qemu#6 0xaaab355845db in parse_object qemu/qobject/json-parser.c:327 qemu#7 0xaaab355845db in parse_value qemu/qobject/json-parser.c:546 qemu#8 0xaaab35585b1b in json_parser_parse qemu/qobject/json-parser.c:580 qemu#9 0xaaab35583703 in json_message_process_token qemu/qobject/json-streamer.c:92 qemu#10 0xaaab355ddccf in json_lexer_feed_char qemu/qobject/json-lexer.c:313 qemu#11 0xaaab355de0eb in json_lexer_feed qemu/qobject/json-lexer.c:350 qemu#12 0xaaab354aff67 in tcp_chr_read qemu/chardev/char-socket.c:525 qemu#13 0xfffe4ae429db in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x529db) qemu#14 0xfffe4ae42d8f (/lib64/libglib-2.0.so.0+0x52d8f) qemu#15 0xfffe4ae430df in g_main_loop_run (/lib64/libglib-2.0.so.0+0x530df) qemu#16 0xaaab34d70bff in iothread_run qemu/iothread.c:82 qemu#17 0xaaab3559d71b in qemu_thread_start qemu/util/qemu-thread-posix.c:519 Fixes: 532fb53 ("qapi: Make more of qobject_to()") Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Alex Chen <alex.chen@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20201113145525.85151-1-alex.chen@huawei.com> [Commit message tweaked]

Properly free resp for get_watchdog_action() to avoid memory leak. ASAN shows memory leak stack: Indirect leak of 12360 byte(s) in 3 object(s) allocated from: #0 0x7f41ab6cbd4e in __interceptor_calloc (/lib64/libasan.so.5+0x112d4e) #1 0x7f41ab4eaa50 in g_malloc0 (/lib64/libglib-2.0.so.0+0x55a50) #2 0x556487d5374b in qdict_new ../qobject/qdict.c:29 qemu#3 0x556487d65e1a in parse_object ../qobject/json-parser.c:318 qemu#4 0x556487d65cb6 in parse_pair ../qobject/json-parser.c:287 qemu#5 0x556487d65ebd in parse_object ../qobject/json-parser.c:343 qemu#6 0x556487d661d5 in json_parser_parse ../qobject/json-parser.c:580 qemu#7 0x556487d513df in json_message_process_token ../qobject/json-streamer.c:92 qemu#8 0x556487d63919 in json_lexer_feed_char ../qobject/json-lexer.c:313 qemu#9 0x556487d63d75 in json_lexer_feed ../qobject/json-lexer.c:350 qemu#10 0x556487d28b2a in qmp_fd_receive ../tests/qtest/libqtest.c:613 qemu#11 0x556487d2a16f in qtest_qmp_eventwait_ref ../tests/qtest/libqtest.c:827 qemu#12 0x556487d248e2 in get_watchdog_action ../tests/qtest/npcm7xx_watchdog_timer-test.c:94 qemu#13 0x556487d25765 in test_enabling_flags ../tests/qtest/npcm7xx_watchdog_timer-test.c:243 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Message-Id: <20201118115646.2461726-3-kuhn.chenqun@huawei.com> Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com> Reviewed-by: Hao Wu <wuhaotsh@google.com> Signed-off-by: Thomas Huth <thuth@redhat.com>

When 'j = icu->nr_sense – 1', the 'j < icu->nr_sense' condition is true, then 'j = icu->nr_sense', the'icu->init_sense[j]' has out-of-bounds access. The asan showed stack: ERROR: AddressSanitizer: heap-buffer-overflow on address 0x604000004d7d at pc 0x55852cd26a76 bp 0x7ffe39f26200 sp 0x7ffe39f261f0 READ of size 1 at 0x604000004d7d thread T0 #0 0x55852cd26a75 in rxicu_realize ../hw/intc/rx_icu.c:311 #1 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886 #2 0x55852cd4a32f in property_set_bool ../qom/object.c:2251 qemu#3 0x55852cd4f9bb in object_property_set ../qom/object.c:1398 qemu#4 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28 qemu#5 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465 qemu#6 0x55852cbf0b27 in register_icu ../hw/rx/rx62n.c:156 qemu#7 0x55852cbf12a6 in rx62n_realize ../hw/rx/rx62n.c:261 qemu#8 0x55852cf075f7 in device_set_realized ../hw/core/qdev.c:886 qemu#9 0x55852cd4a32f in property_set_bool ../qom/object.c:2251 qemu#10 0x55852cd4f9bb in object_property_set ../qom/object.c:1398 qemu#11 0x55852cd54f3f in object_property_set_qobject ../qom/qom-qobject.c:28 qemu#12 0x55852cd4fc3f in object_property_set_bool ../qom/object.c:1465 qemu#13 0x55852cbf1a85 in rx_gdbsim_init ../hw/rx/rx-gdbsim.c:109 qemu#14 0x55852cd22de0 in qemu_init ../softmmu/vl.c:4380 qemu#15 0x55852ca57088 in main ../softmmu/main.c:49 qemu#16 0x7feefafa5d42 in __libc_start_main (/lib64/libc.so.6+0x26d42) Add the 'ice->src[i].sense' initialize to the default value, and then process init_sense array to identify which irqs should be level-triggered. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20201111141733.2358800-1-kuhn.chenqun@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Document the 3 front LEDs modeled on the OpenPOWER Witherspoon BMC (see commit 7cfbde5 "hw/arm/aspeed: Add the 3 front LEDs drived by the PCA9552 #1"). Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20201120173953.2539469-4-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

When running device-introspect-test, a memory leak occurred in the s390_cpu_initfn function, this patch use timer_free() in the finalize function to fix it. ASAN shows memory leak stack: Direct leak of 3552 byte(s) in 74 object(s) allocated from: #0 0xfffeb3d4e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xfffeb36e6800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaad51a8f9c4 in timer_new_full qemu/include/qemu/timer.h:523 qemu#3 0xaaad51a8f9c4 in timer_new qemu/include/qemu/timer.h:544 qemu#4 0xaaad51a8f9c4 in timer_new_ns qemu/include/qemu/timer.h:562 qemu#5 0xaaad51a8f9c4 in s390_cpu_initfn qemu/target/s390x/cpu.c:304 qemu#6 0xaaad51e00f58 in object_init_with_type qemu/qom/object.c:371 qemu#7 0xaaad51e0406c in object_initialize_with_type qemu/qom/object.c:515 qemu#8 0xaaad51e042e0 in object_new_with_type qemu/qom/object.c:729 qemu#9 0xaaad51e3ff40 in qmp_device_list_properties qemu/qom/qom-qmp-cmds.c:153 qemu#10 0xaaad51910518 in qdev_device_help qemu/softmmu/qdev-monitor.c:283 qemu#11 0xaaad51911918 in qmp_device_add qemu/softmmu/qdev-monitor.c:801 qemu#12 0xaaad51911e48 in hmp_device_add qemu/softmmu/qdev-monitor.c:916 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: David Hildenbrand <david@redhat.com> Message-Id: <20201204081209.360524-4-ganqixin@huawei.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>

Providing the 'if' property, but not 'canbus' segfaults like this: #0 0x0000555555b0f14d in can_bus_insert_client (bus=0x0, client=0x555556aa9af0) at ../net/can/can_core.c:88 #1 0x00005555559c3803 in can_host_connect (ch=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:62 #2 0x00005555559c386a in can_host_complete (uc=0x555556aa9ac0, errp=0x7fffffffd568) at ../net/can/can_host.c:72 qemu#3 0x0000555555d52de9 in user_creatable_complete (uc=0x555556aa9ac0, errp=0x7fffffffd5c8) at ../qom/object_interfaces.c:23 Add the missing NULL check. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20201130105615.21799-5-kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

When running qom-test, a memory leak occurred in the ppce500_init function, this patch free irqs array to fix it. ASAN shows memory leak stack: Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0xfffc5ceee1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xfffc5c806800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaacf9999244 in ppce500_init qemu/hw/ppc/e500.c:859 qemu#3 0xaaacf97434e8 in machine_run_board_init qemu/hw/core/machine.c:1134 qemu#4 0xaaacf9c9475c in qemu_init qemu/softmmu/vl.c:4369 qemu#5 0xaaacf94785a0 in main qemu/softmmu/main.c:49 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Message-Id: <20201204075822.359832-1-ganqixin@huawei.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

In rom_check_and_register_reset() we report to the user if there is a "ROM region overlap". This has a couple of problems: * the reported information is not very easy to intepret * the function just prints the overlap to stderr (and relies on its single callsite in vl.c to do an error_report() and exit) * only the first overlap encountered is diagnosed Make this function use error_report() and error_printf() and report a more user-friendly report with all the overlaps diagnosed. Sample old output: rom: requested regions overlap (rom dtb. free=0x0000000000008000, addr=0x0000000000000000) qemu-system-aarch64: rom check and register reset failed Sample new output: qemu-system-aarch64: Some ROM regions are overlapping These ROM regions might have been loaded by direct user request or by default. They could be BIOS/firmware images, a guest kernel, initrd or some other file loaded into guest memory. Check whether you intended to load all this guest code, and whether it has been built to load to the correct addresses. The following two regions overlap (in the cpu-memory-0 address space): phdr #0: /home/petmay01/linaro/qemu-misc-tests/ldmia-fault.axf (addresses 0x0000000000000000 - 0x0000000000008000) dtb (addresses 0x0000000000000000 - 0x0000000000100000) The following two regions overlap (in the cpu-memory-0 address space): phdr #1: /home/petmay01/linaro/qemu-misc-tests/bad-psci-call.axf (addresses 0x0000000040000000 - 0x0000000040000010) phdr #0: /home/petmay01/linaro/qemu-misc-tests/bp-test.elf (addresses 0x0000000040000000 - 0x0000000040000020) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20201129203923.10622-3-peter.maydell@linaro.org

In host_memory_backend_get_host_nodes, we build host_nodes list and output it to v (a StringOutputVisitor) but forget to free the list. This fixes the memory leak. The memory leak stack: Direct leak of 32 byte(s) in 2 object(s) allocated from: #0 0xfffda30b3393 in __interceptor_calloc (/usr/lib64/libasan.so.4+0xd3393) #1 0xfffda1d28b9b in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x58b9b) #2 0xaaab05ca6e43 in host_memory_backend_get_host_nodes backends/hostmem.c:94 qemu#3 0xaaab061ddf83 in object_property_get_uint16List qom/object.c:1478 qemu#4 0xaaab05866513 in query_memdev hw/core/machine-qmp-cmds.c:312 qemu#5 0xaaab061d980b in do_object_child_foreach qom/object.c:1001 qemu#6 0xaaab0586779b in qmp_query_memdev hw/core/machine-qmp-cmds.c:328 qemu#7 0xaaab0615ed3f in qmp_marshal_query_memdev qapi/qapi-commands-machine.c:327 qemu#8 0xaaab0632d647 in do_qmp_dispatch qapi/qmp-dispatch.c:147 qemu#9 0xaaab0632d647 in qmp_dispatch qapi/qmp-dispatch.c:190 qemu#10 0xaaab0610f74b in monitor_qmp_dispatch monitor/qmp.c:120 qemu#11 0xaaab0611074b in monitor_qmp_bh_dispatcher monitor/qmp.c:209 qemu#12 0xaaab063caefb in aio_bh_poll util/async.c:117 qemu#13 0xaaab063d30fb in aio_dispatch util/aio-posix.c:459 qemu#14 0xaaab063cac8f in aio_ctx_dispatch util/async.c:268 qemu#15 0xfffda1d22a6b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a6b) qemu#16 0xaaab063d0e97 in glib_pollfds_poll util/main-loop.c:218 qemu#17 0xaaab063d0e97 in os_host_main_loop_wait util/main-loop.c:241 qemu#18 0xaaab063d0e97 in main_loop_wait util/main-loop.c:517 qemu#19 0xaaab05c8bfa7 in main_loop /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:1791 qemu#20 0xaaab05713bc3 in main /root/rpmbuild/BUILD/qemu-4.1.0/vl.c:4473 qemu#21 0xfffda0a83ebf in __libc_start_main (/usr/lib64/libc.so.6+0x23ebf) qemu#22 0xaaab0571ed5f (aarch64-softmmu/qemu-system-aarch64+0x88ed5f) SUMMARY: AddressSanitizer: 32 byte(s) leaked in 2 allocation(s). Fixes: 4cf1b76 (hostmem: add properties for NUMA memory policy) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com> Tested-by: Chen Qun <kuhn.chenqun@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20201210075226.20196-1-zhukeqian1@huawei.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>

The kernel comes from debian archive so it's trusted. Invoking the test can be done as follows: $ avocado --show=app,console run -t machine:fuloong2e tests/acceptance/ (1/1) tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips64el_fuloong2e: console: [ 0.000000] Initializing cgroup subsys cpuset console: [ 0.000000] Initializing cgroup subsys cpu console: [ 0.000000] Initializing cgroup subsys cpuacct console: [ 0.000000] Linux version 3.16.0-6-loongson-2e (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.56-1+deb8u1 (2018-05-08) console: [ 0.000000] memsize=256, highmemsize=0 console: [ 0.000000] CpuClock = 533080000 console: [ 0.000000] bootconsole [early0] enabled console: [ 0.000000] CPU0 revision is: 00006302 (ICT Loongson-2) console: [ 0.000000] FPU revision is: 00000501 console: [ 0.000000] Checking for the multiply/shift bug... no. console: [ 0.000000] Checking for the daddiu bug... no. console: [ 0.000000] Determined physical RAM map: console: [ 0.000000] memory: 0000000010000000 @ 0000000000000000 (usable) console: [ 0.000000] memory: 0000000004000000 @ 0000000010000000 (reserved) console: [ 0.000000] memory: 0000000003ffffff @ 000000001c000001 (reserved) console: [ 0.000000] Initrd not found or empty - disabling initrd console: [ 0.000000] Zone ranges: console: [ 0.000000] DMA [mem 0x00000000-0x00ffffff] console: [ 0.000000] Normal [mem 0x01000000-0x0fffffff] console: [ 0.000000] Movable zone start for each node console: [ 0.000000] Early memory node ranges console: [ 0.000000] node 0: [mem 0x00000000-0x0fffffff] console: [ 0.000000] Reserving 0MB of memory at 0MB for crashkernel console: [ 0.000000] Primary instruction cache 64kB, VIPT, direct mapped, linesize 32 bytes. console: [ 0.000000] Primary data cache 64kB, 4-way, VIPT, no aliases, linesize 32 bytes console: [ 0.000000] Unified secondary cache 512kB 4-way, linesize 32 bytes. console: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16327 console: [ 0.000000] Kernel command line: printk.time=0 console=ttyS0 PASS (2.27 s) Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> Reviewed-by: Willian Rampazzo <willianr@redhat.com> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201224031750.52146-9-jiaxun.yang@flygoat.com> [PMD: Added command line example] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

…eaks When running device-introspect-test, a memory leak occurred in the digic_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 3 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 qemu#3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…d memleaks When running device-introspect-test, a memory leak occurred in the a10_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 6 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278 qemu#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49 qemu#11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_rtc_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 qemu#3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 qemu#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 qemu#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 qemu#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_pwm_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 240 byte(s) in 5 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401 qemu#7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

When running device-introspect-test, a memory leak occurred in the mss_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 2 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 qemu#3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 qemu#6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 qemu#7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

When running device-introspect-test, a memory leak occurred in the mv88w8618_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 4 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 qemu#3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 qemu#4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 qemu#5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 qemu#6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862 qemu#7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954 qemu#8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283 qemu#12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

…emleaks When running device-introspect-test, a memory leak occurred in the exynos4210_mct_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 qemu#3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505 qemu#4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 qemu#5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 qemu#6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 qemu#7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 qemu#8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 qemu#9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 qemu#10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 qemu#11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 qemu#12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

When the length of mname is less than 5, memcpy("xenfv", mname, 5) will cause heap buffer overflow. Therefore, use strncmp to avoid this problem. The asan showed stack: ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000f2f4 at pc 0x7f65d8cc2225 bp 0x7ffe93cc5a60 sp 0x7ffe93cc5208 READ of size 5 at 0x60200000f2f4 thread T0 #0 0x7f65d8cc2224 in memcmp (/lib64/libasan.so.5+0xdf224) #1 0x5632c20be95b in qtest_cb_for_every_machine tests/qtest/libqtest.c:1282 #2 0x5632c20b7995 in main tests/qtest/test-hmp.c:160 qemu#3 0x7f65d88fed42 in __libc_start_main (/lib64/libc.so.6+0x26d42) qemu#4 0x5632c20b72cd in _start (build/tests/qtest/test-hmp+0x542cd) Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20210106050625.518041-1-ganqixin@huawei.com> Signed-off-by: Thomas Huth <thuth@redhat.com>

…ier() In the failover case configuration, virtio_net_device_realize() uses an add_migration_state_change_notifier() to add a state notifier, but this notifier is not removed by the unrealize function when the virtio-net card is unplugged. If the card is unplugged and a migration is started, the notifier is called and as it is not valid anymore QEMU crashes. This patch fixes the problem by adding the remove_migration_state_change_notifier() in virtio_net_device_unrealize(). The problem can be reproduced with: $ qemu-system-x86_64 -enable-kvm -m 1g -M q35 \ -device pcie-root-port,slot=4,id=root1 \ -device pcie-root-port,slot=5,id=root2 \ -device virtio-net-pci,id=net1,mac=52:54:00:6f:55:cc,failover=on,bus=root1 \ -monitor stdio disk.qcow2 (qemu) device_del net1 (qemu) migrate "exec:gzip -c > STATEFILE.gz" Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in () #1 0x0000555555d726d7 in notifier_list_notify (...) at .../util/notify.c:39 #2 0x0000555555842c1a in migrate_fd_connect (...) at .../migration/migration.c:3975 qemu#3 0x0000555555950f7d in migration_channel_connect (...) error@entry=0x0) at .../migration/channel.c:107 qemu#4 0x0000555555910922 in exec_start_outgoing_migration (...) at .../migration/exec.c:42 Reported-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com>

Commit 3ca1f32 "block: BdrvChildClass: add .get_parent_aio_context handler" introduced new handler and commit 228ca37 "block: drop ctx argument from bdrv_root_attach_child" made a generic use of it. But 3ca1f32 didn't update child_vvfat_qcow. Fix that. Before that fix the command ./build/qemu-system-x86_64 -usb -device usb-storage,drive=fat16 \ -drive file=fat:rw:fat-type=16:"<path of a host folder>",id=fat16,format=raw,if=none crashes: 1 bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 2 bdrv_attach_child_common (child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, perm=3, shared_perm=4, opaque=0x559d62445690, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2795 3 bdrv_attach_child_noperm (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, child=0x7ffc74c2acc8, tran=0x559d6246ddd0, errp=0x7ffc74c2ae60) at ../block.c:2855 4 bdrv_attach_child (parent_bs=0x559d62445690, child_bs=0x559d62468190, child_name=0x559d606f9e3d "write-target", child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, errp=0x7ffc74c2ae60) at ../block.c:2953 5 bdrv_open_child (filename=0x559d62464b80 "/var/tmp/vl.h3TIS4", options=0x559d6246ec20, bdref_key=0x559d606f9e3d "write-target", parent=0x559d62445690, child_class=0x559d60c58d20 <child_vvfat_qcow>, child_role=3, allow_none=false, errp=0x7ffc74c2ae60) at ../block.c:3351 6 enable_write_target (bs=0x559d62445690, errp=0x7ffc74c2ae60) at ../block/vvfat.c:3176 7 vvfat_open (bs=0x559d62445690, options=0x559d6244adb0, flags=155650, errp=0x7ffc74c2ae60) at ../block/vvfat.c:1236 8 bdrv_open_driver (bs=0x559d62445690, drv=0x559d60d4f7e0 <bdrv_vvfat>, node_name=0x0, options=0x559d6244adb0, open_flags=155650, errp=0x7ffc74c2af70) at ../block.c:1557 9 bdrv_open_common (bs=0x559d62445690, file=0x0, options=0x559d6244adb0, errp=0x7ffc74c2af70) at ... (gdb) fr 1 #1 0x0000559d603ea3bf in bdrv_child_get_parent_aio_context (c=0x559d62426d20) at ../block.c:1440 1440 return c->klass->get_parent_aio_context(c); (gdb) p c->klass $1 = (const BdrvChildClass *) 0x559d60c58d20 <child_vvfat_qcow> (gdb) p c->klass->get_parent_aio_context $2 = (AioContext *(*)(BdrvChild *)) 0x0 Fixes: 3ca1f32 Fixes: 228ca37 Reported-by: John Arbuckle <programmingkidx@gmail.com> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20210524101257.119377-2-vsementsov@virtuozzo.com> Tested-by: John Arbuckle <programmingkidx@gmail.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>

This patch fixes the following: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f6ae4559859 in __GI_abort () at abort.c:79 #2 0x0000559aaa386720 in error_exit (err=16, msg=0x559aaa5973d0 <__func__.16227> "qemu_mutex_destroy") at util/qemu-thread-posix.c:36 qemu#3 0x0000559aaa3868c5 in qemu_mutex_destroy (mutex=0x559aabffe828) at util/qemu-thread-posix.c:69 qemu#4 0x0000559aaa2f93a8 in char_finalize (obj=0x559aabffe800) at chardev/char.c:285 qemu#5 0x0000559aaa23318a in object_deinit (obj=0x559aabffe800, type=0x559aabfd7d20) at qom/object.c:606 qemu#6 0x0000559aaa2331b8 in object_deinit (obj=0x559aabffe800, type=0x559aabfd9060) at qom/object.c:610 qemu#7 0x0000559aaa233200 in object_finalize (data=0x559aabffe800) at qom/object.c:620 qemu#8 0x0000559aaa234202 in object_unref (obj=0x559aabffe800) at qom/object.c:1074 qemu#9 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0dac10, name=0x559aac778760 "compare0-0", opaque=0x559aabffe800) at qom/object.c:1584 qemu#10 0x0000559aaa232f70 in object_property_del_all (obj=0x559aac0dac10) at qom/object.c:557 qemu#11 0x0000559aaa2331ed in object_finalize (data=0x559aac0dac10) at qom/object.c:619 qemu#12 0x0000559aaa234202 in object_unref (obj=0x559aac0dac10) at qom/object.c:1074 qemu#13 0x0000559aaa2356b6 in object_finalize_child_property (obj=0x559aac0c75c0, name=0x559aac0dadc0 "chardevs", opaque=0x559aac0dac10) at qom/object.c:1584 qemu#14 0x0000559aaa233071 in object_property_del_child (obj=0x559aac0c75c0, child=0x559aac0dac10, errp=0x0) at qom/object.c:580 qemu#15 0x0000559aaa233155 in object_unparent (obj=0x559aac0dac10) at qom/object.c:599 qemu#16 0x0000559aaa2fb721 in qemu_chr_cleanup () at chardev/char.c:1159 qemu#17 0x0000559aa9f9b110 in main (argc=54, argv=0x7ffeb62fa998, envp=0x7ffeb62fab50) at vl.c:4539 When chardev is cleaned up, chr_write_lock needs to be destroyed. But the colo-compare module is not cleaned up normally before it when the guest poweroff. It is holding chr_write_lock at this time. This will cause qemu crash.So we add the function of colo_compare_cleanup() before qemu_chr_cleanup() to fix the bug. Signed-off-by: Lei Rao <lei.rao@intel.com> Reviewed-by: Zhang Chen <chen.zhang@intel.com> Reviewed-by: Lukas Straub <lukasstraub2@web.de> Tested-by: Lukas Straub <lukasstraub2@web.de> Signed-off-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com>

While the SB16 seems to work up to 48000 Hz, the "Sound Blaster Series Hardware Programming Guide" limit the sampling range from 4000 Hz to 44100 Hz (Section 3-9, 3-10: Digitized Sound I/O Programming, tables 3-2 and 3-3). Later, section 6-15 (DSP Commands) is more specific regarding the 41h / 42h registers (Set digitized sound output sampling rate): Valid sampling rates range from 5000 to 45000 Hz inclusive. There is no comment regarding error handling if the register is filled with an out-of-range value. (See also section 3-28 "8-bit or 16-bit Auto-initialize Transfer"). Assume limits are enforced in hardware. This fixes triggering an assertion in audio_calloc(): #1 abort #2 audio_bug audio/audio.c:119:9 qemu#3 audio_calloc audio/audio.c:154:9 qemu#4 audio_pcm_sw_alloc_resources_out audio/audio_template.h:116:15 qemu#5 audio_pcm_sw_init_out audio/audio_template.h:175:11 qemu#6 audio_pcm_create_voice_pair_out audio/audio_template.h:410:9 qemu#7 AUD_open_out audio/audio_template.h:503:14 qemu#8 continue_dma8 hw/audio/sb16.c:216:20 qemu#9 dma_cmd8 hw/audio/sb16.c:276:5 qemu#10 command hw/audio/sb16.c:0 qemu#11 dsp_write hw/audio/sb16.c:949:13 qemu#12 portio_write softmmu/ioport.c:205:13 qemu#13 memory_region_write_accessor softmmu/memory.c:491:5 qemu#14 access_with_adjusted_size softmmu/memory.c:552:18 qemu#15 memory_region_dispatch_write softmmu/memory.c:0:13 qemu#16 flatview_write_continue softmmu/physmem.c:2759:23 qemu#17 flatview_write softmmu/physmem.c:2799:14 qemu#18 address_space_write softmmu/physmem.c:2891:18 qemu#19 cpu_outw softmmu/ioport.c:70:5 [*] http://www.baudline.com/solutions/full_duplex/sb16_pci/index.html OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29174 Fixes: 85571bc ("audio merge (malc)") Buglink: https://bugs.launchpad.net/bugs/1910603 Tested-by: Qiang Liu <cyruscyliu@gmail.com> Reviewed-by: Qiang Liu <cyruscyliu@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210616104349.2398060-1-f4bug@amsat.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

backtrace: '0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 478 void *addr = mr->addr; (gdb) bt #0 0x00007ffff5f44ec2 in __ibv_dereg_mr_1_1 (mr=0x7fff1007d390) at /home/lizhijian/rdma-core/libibverbs/verbs.c:478 #1 0x0000555555891fcc in rdma_delete_block (block=<optimized out>, rdma=0x7fff38176010) at ../migration/rdma.c:691 #2 qemu_rdma_cleanup (rdma=0x7fff38176010) at ../migration/rdma.c:2365 qemu#3 0x00005555558925b0 in qio_channel_rdma_close_rcu (rcu=0x555556b8b6c0) at ../migration/rdma.c:3073 qemu#4 0x0000555555d652a3 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:281 qemu#5 0x0000555555d5edf9 in qemu_thread_start (args=0x7fffe88bb4d0) at ../util/qemu-thread-posix.c:541 qemu#6 0x00007ffff54c73f9 in start_thread () at /lib64/libpthread.so.0 qemu#7 0x00007ffff53f3b03 in clone () at /lib64/libc.so.6 ' Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Message-Id: <20210708144521.1959614-1-lizhijian@cn.fujitsu.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

When building the Pegasos2 machine stand-alone we get: $ qemu-system-ppc -M pegasos2 -bios pegasos2.rom ERROR:qom/object.c:714:object_new_with_type: assertion failed: (type != NULL) Bail out! ERROR:qom/object.c:714:object_new_with_type: assertion failed: (type != NULL) Looking at the backtraces: Thread 1 "qemu-system-ppc" received signal SIGABRT, Aborted. (gdb) bt #0 0x00007ffff53877d5 in raise () at /lib64/libc.so.6 #1 0x00007ffff5370895 in abort () at /lib64/libc.so.6 #2 0x00007ffff6dc4b6c in g_assertion_message_expr.cold () at /lib64/libglib-2.0.so.0 qemu#3 0x00007ffff6e229ff in g_assertion_message_expr () at /lib64/libglib-2.0.so.0 qemu#4 0x0000555555a0c8f4 in object_new_with_type (type=0x0) at qom/object.c:714 qemu#5 0x0000555555a0c9d5 in object_new (typename=0x555555c7afe4 "isa-pit") at qom/object.c:747 qemu#6 0x0000555555a053b8 in qdev_new (name=0x555555c7afe4 "isa-pit") at hw/core/qdev.c:153 qemu#7 0x00005555557cdd05 in isa_new (name=0x555555c7afe4 "isa-pit") at hw/isa/isa-bus.c:160 qemu#8 0x00005555557cf518 in i8254_pit_init (bus=0x55555603d140, base=64, isa_irq=0, alt_irq=0x0) at include/hw/timer/i8254.h:54 qemu#9 0x00005555557d12f9 in vt8231_realize (d=0x5555563d9770, errp=0x7fffffffcc28) at hw/isa/vt82c686.c:704 (gdb) bt #0 0x00007ffff54bd7d5 in raise () at /lib64/libc.so.6 #1 0x00007ffff54a6895 in abort () at /lib64/libc.so.6 #2 0x00005555558f7796 in object_new (typename=0x555555ad4889 "isa-parallel") at qom/object.c:749 qemu#3 object_new (typename=type0x555555ad4889 "isa-parallel") at qom/object.c:743 qemu#4 0x00005555558f0d46 in qdev_new (name=0x555555ad4889 "isa-parallel") at hw/core/qdev.c:153 qemu#5 0x000055555576b669 in isa_new (name=0x555555ad4889 "isa-parallel") at hw/isa/isa-bus.c:160 qemu#6 0x000055555576bbe8 in isa_superio_realize (dev=0x555555f15910, errp=<optimized out>) at hw/isa/isa-superio.c:54 qemu#7 0x000055555576d5ed in via_superio_realize (d=0x555555f15910, errp=0x7fffffffcb30) at hw/isa/vt82c686.c:292 qemu#8 0x00005555558f12c1 in device_set_realized (obj=<optimized out>, ...) at hw/core/qdev.c:761 qemu#9 0x00005555558f5066 in property_set_bool (obj=0x555555f15910, ..., errp=0x7fffffffcbb0) at qom/object.c:2262 qemu#10 0x00005555558f7f38 in object_property_set (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/object.c:1407 qemu#11 0x00005555558fb2d0 in object_property_set_qobject (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/qom-qobject.c:28 qemu#12 0x00005555558f8525 in object_property_set_bool (obj=0x555555f15910, name=0x555555b1b1e3 "realized", ...) at qom/object.c:1477 qemu#13 0x00005555558f18ee in qdev_realize (dev=0x555555f15910, bus=0x55555602a610, errp=<optimized out>) at hw/core/qdev.c:389 qemu#14 0x00005555558f197f in qdev_realize_and_unref (dev=0x555555f15910, bus=0x55555602a610, errp=<optimized out>) at hw/core/qdev.c:396 qemu#15 0x000055555576b709 in isa_realize_and_unref (errp=<optimized out>, bus=0x55555602a610, dev=0x555555f15910) at hw/isa/isa-bus.c:179 qemu#16 isa_create_simple (bus=0x55555602a610, name=0x555555adc33b "vt8231-superio") at hw/isa/isa-bus.c:173 qemu#17 0x000055555576d9b7 in vt8231_realize (d=0x555556186a50, errp=<optimized out>) at hw/isa/vt82c686.c:706 The "isa-pit" type (TYPE_I8254) and "isa-parallel" are missing. Add them. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210515173716.358295-12-philmd@redhat.com> [PMD: Added "isa-parallel" later]

Instantiate SAI1/2/3 and ASRC as unimplemented devices to avoid random Linux kernel crashes, such as Unhandled fault: external abort on non-linefetch (0x808) at 0xd1580010 pgd = (ptrval) [d1580010] *pgd=8231b811, *pte=02034653, *ppte=02034453 Internal error: : 808 [#1] SMP ARM ... [<c095e974>] (regmap_mmio_write32le) from [<c095eb48>] (regmap_mmio_write+0x3c/0x54) [<c095eb48>] (regmap_mmio_write) from [<c09580f4>] (_regmap_write+0x4c/0x1f0) [<c09580f4>] (_regmap_write) from [<c095837c>] (_regmap_update_bits+0xe4/0xec) [<c095837c>] (_regmap_update_bits) from [<c09599b4>] (regmap_update_bits_base+0x50/0x74) [<c09599b4>] (regmap_update_bits_base) from [<c0d3e9e4>] (fsl_asrc_runtime_resume+0x1e4/0x21c) [<c0d3e9e4>] (fsl_asrc_runtime_resume) from [<c0942464>] (__rpm_callback+0x3c/0x108) [<c0942464>] (__rpm_callback) from [<c0942590>] (rpm_callback+0x60/0x64) [<c0942590>] (rpm_callback) from [<c0942b60>] (rpm_resume+0x5cc/0x808) [<c0942b60>] (rpm_resume) from [<c0942dfc>] (__pm_runtime_resume+0x60/0xa0) [<c0942dfc>] (__pm_runtime_resume) from [<c0d3ecc4>] (fsl_asrc_probe+0x2a8/0x708) [<c0d3ecc4>] (fsl_asrc_probe) from [<c0935b08>] (platform_probe+0x58/0xb8) [<c0935b08>] (platform_probe) from [<c0933264>] (really_probe.part.0+0x9c/0x334) [<c0933264>] (really_probe.part.0) from [<c093359c>] (__driver_probe_device+0xa0/0x138) [<c093359c>] (__driver_probe_device) from [<c0933664>] (driver_probe_device+0x30/0xc8) [<c0933664>] (driver_probe_device) from [<c0933c88>] (__driver_attach+0x90/0x130) [<c0933c88>] (__driver_attach) from [<c0931060>] (bus_for_each_dev+0x78/0xb8) [<c0931060>] (bus_for_each_dev) from [<c093254c>] (bus_add_driver+0xf0/0x1d8) [<c093254c>] (bus_add_driver) from [<c0934a30>] (driver_register+0x88/0x118) [<c0934a30>] (driver_register) from [<c01022c0>] (do_one_initcall+0x7c/0x3a4) [<c01022c0>] (do_one_initcall) from [<c1601204>] (kernel_init_freeable+0x198/0x22c) [<c1601204>] (kernel_init_freeable) from [<c0f5ff2c>] (kernel_init+0x10/0x128) [<c0f5ff2c>] (kernel_init) from [<c010013c>] (ret_from_fork+0x14/0x38) or Unhandled fault: external abort on non-linefetch (0x808) at 0xd19b0000 pgd = (ptrval) [d19b0000] *pgd=82711811, *pte=308a0653, *ppte=308a0453 Internal error: : 808 [#1] SMP ARM ... [<c095e974>] (regmap_mmio_write32le) from [<c095eb48>] (regmap_mmio_write+0x3c/0x54) [<c095eb48>] (regmap_mmio_write) from [<c09580f4>] (_regmap_write+0x4c/0x1f0) [<c09580f4>] (_regmap_write) from [<c0959b28>] (regmap_write+0x3c/0x60) [<c0959b28>] (regmap_write) from [<c0d41130>] (fsl_sai_runtime_resume+0x9c/0x1ec) [<c0d41130>] (fsl_sai_runtime_resume) from [<c0942464>] (__rpm_callback+0x3c/0x108) [<c0942464>] (__rpm_callback) from [<c0942590>] (rpm_callback+0x60/0x64) [<c0942590>] (rpm_callback) from [<c0942b60>] (rpm_resume+0x5cc/0x808) [<c0942b60>] (rpm_resume) from [<c0942dfc>] (__pm_runtime_resume+0x60/0xa0) [<c0942dfc>] (__pm_runtime_resume) from [<c0d4231c>] (fsl_sai_probe+0x2b8/0x65c) [<c0d4231c>] (fsl_sai_probe) from [<c0935b08>] (platform_probe+0x58/0xb8) [<c0935b08>] (platform_probe) from [<c0933264>] (really_probe.part.0+0x9c/0x334) [<c0933264>] (really_probe.part.0) from [<c093359c>] (__driver_probe_device+0xa0/0x138) [<c093359c>] (__driver_probe_device) from [<c0933664>] (driver_probe_device+0x30/0xc8) [<c0933664>] (driver_probe_device) from [<c0933c88>] (__driver_attach+0x90/0x130) [<c0933c88>] (__driver_attach) from [<c0931060>] (bus_for_each_dev+0x78/0xb8) [<c0931060>] (bus_for_each_dev) from [<c093254c>] (bus_add_driver+0xf0/0x1d8) [<c093254c>] (bus_add_driver) from [<c0934a30>] (driver_register+0x88/0x118) [<c0934a30>] (driver_register) from [<c01022c0>] (do_one_initcall+0x7c/0x3a4) [<c01022c0>] (do_one_initcall) from [<c1601204>] (kernel_init_freeable+0x198/0x22c) [<c1601204>] (kernel_init_freeable) from [<c0f5ff2c>] (kernel_init+0x10/0x128) [<c0f5ff2c>] (kernel_init) from [<c010013c>] (ret_from_fork+0x14/0x38) Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20210810160318.87376-1-linux@roeck-us.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Instantiate SAI1/2/3 as unimplemented devices to avoid Linux kernel crashes such as the following. Unhandled fault: external abort on non-linefetch (0x808) at 0xd19b0000 pgd = (ptrval) [d19b0000] *pgd=82711811, *pte=308a0653, *ppte=308a0453 Internal error: : 808 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc5 #1 ... [<c095e974>] (regmap_mmio_write32le) from [<c095eb48>] (regmap_mmio_write+0x3c/0x54) [<c095eb48>] (regmap_mmio_write) from [<c09580f4>] (_regmap_write+0x4c/0x1f0) [<c09580f4>] (_regmap_write) from [<c0959b28>] (regmap_write+0x3c/0x60) [<c0959b28>] (regmap_write) from [<c0d41130>] (fsl_sai_runtime_resume+0x9c/0x1ec) [<c0d41130>] (fsl_sai_runtime_resume) from [<c0942464>] (__rpm_callback+0x3c/0x108) [<c0942464>] (__rpm_callback) from [<c0942590>] (rpm_callback+0x60/0x64) [<c0942590>] (rpm_callback) from [<c0942b60>] (rpm_resume+0x5cc/0x808) [<c0942b60>] (rpm_resume) from [<c0942dfc>] (__pm_runtime_resume+0x60/0xa0) [<c0942dfc>] (__pm_runtime_resume) from [<c0d4231c>] (fsl_sai_probe+0x2b8/0x65c) [<c0d4231c>] (fsl_sai_probe) from [<c0935b08>] (platform_probe+0x58/0xb8) [<c0935b08>] (platform_probe) from [<c0933264>] (really_probe.part.0+0x9c/0x334) [<c0933264>] (really_probe.part.0) from [<c093359c>] (__driver_probe_device+0xa0/0x138) [<c093359c>] (__driver_probe_device) from [<c0933664>] (driver_probe_device+0x30/0xc8) [<c0933664>] (driver_probe_device) from [<c0933c88>] (__driver_attach+0x90/0x130) [<c0933c88>] (__driver_attach) from [<c0931060>] (bus_for_each_dev+0x78/0xb8) [<c0931060>] (bus_for_each_dev) from [<c093254c>] (bus_add_driver+0xf0/0x1d8) [<c093254c>] (bus_add_driver) from [<c0934a30>] (driver_register+0x88/0x118) [<c0934a30>] (driver_register) from [<c01022c0>] (do_one_initcall+0x7c/0x3a4) [<c01022c0>] (do_one_initcall) from [<c1601204>] (kernel_init_freeable+0x198/0x22c) [<c1601204>] (kernel_init_freeable) from [<c0f5ff2c>] (kernel_init+0x10/0x128) [<c0f5ff2c>] (kernel_init) from [<c010013c>] (ret_from_fork+0x14/0x38) Signed-off-by: Guenter Roeck <linux@roeck-us.net> Message-id: 20210810175607.538090-1-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

In mirror_iteration() we call mirror_wait_on_conflicts() with `self` parameter set to NULL. Starting from commit d44dae1 we dereference `self` pointer in mirror_wait_on_conflicts() without checks if it is not NULL. Backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 mirror_wait_on_conflicts (self=0x0, s=<optimized out>, offset=<optimized out>, bytes=<optimized out>) at ../block/mirror.c:172 172 self->waiting_for_op = op; [Current thread is 1 (Thread 0x7f0908931ec0 (LWP 380249))] (gdb) bt #0 mirror_wait_on_conflicts (self=0x0, s=<optimized out>, offset=<optimized out>, bytes=<optimized out>) at ../block/mirror.c:172 #1 0x00005610c5d9d631 in mirror_run (job=0x5610c76a2c00, errp=<optimized out>) at ../block/mirror.c:491 #2 0x00005610c5d58726 in job_co_entry (opaque=0x5610c76a2c00) at ../job.c:917 qemu#3 0x00005610c5f046c6 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at ../util/coroutine-ucontext.c:173 qemu#4 0x00007f0909975820 in ?? () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 from /usr/lib64/libc.so.6 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2001404 Fixes: d44dae1 ("block/mirror: fix active mirror dead-lock in mirror_wait_on_conflicts") Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20210910124533.288318-1-sgarzare@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Hanna Reitz <hreitz@redhat.com>

Both qemu and qemu-img use writeback cache mode by default, which is already documented in qemu(1). qemu-nbd uses writethrough cache mode by default, and the default cache mode is not documented. According to the qemu-nbd(8): --cache=CACHE The cache mode to be used with the file. See the documentation of the emulator's -drive cache=... option for allowed values. qemu(1) says: The default mode is cache=writeback. So users have no reason to assume that qemu-nbd is using writethough cache mode. The only hint is the painfully slow writing when using the defaults. Looking in git history, it seems that qemu used writethrough in the past to support broken guests that did not flush data properly, or could not flush due to limitations in qemu. But qemu-nbd clients can use NBD_CMD_FLUSH to flush data, so using writethrough does not help anyone. Change the default cache mode to writback, and document the default and available values properly in the online help and manual. With this change converting image via qemu-nbd is 3.5 times faster. $ qemu-img create dst.img 50g $ qemu-nbd -t -f raw -k /tmp/nbd.sock dst.img Before this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 83.639 s ± 5.970 s [User: 2.733 s, System: 6.112 s] Range (min … max): 76.749 s … 87.245 s 3 runs After this change: $ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock" Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img nbd+unix:///?socket=/tmp/nbd.sock Time (mean ± σ): 23.522 s ± 0.433 s [User: 2.083 s, System: 5.475 s] Range (min … max): 23.234 s … 24.019 s 3 runs Users can avoid the issue by using --cache=writeback[1] but the defaults should give good performance for the common use case. [1] https://bugzilla.redhat.com/1990656 Signed-off-by: Nir Soffer <nsoffer@redhat.com> Message-Id: <20210813205519.50518-1-nsoffer@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>

franciozzy added 3 commits October 14, 2016 03:16

libvhost-user: fix build

34637ac

This patch fix three simple errors that are preventing libvhost-user from building. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

libvhost-user: update shadow avail idx on SET_VRING_BASE

0e4f06c

The shadow copy of the last_avail_idx must also be updated upon receiving a SET_VRING_BASE message. Signed-off-by: Felipe Franciosi <felipe@nutanix.com>

franciozzy added 2 commits October 25, 2016 10:12

elmarco closed this Mar 23, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Libvhost user #1

Libvhost user #1

franciozzy commented Oct 14, 2016

Libvhost user #1

Libvhost user #1

Conversation

franciozzy commented Oct 14, 2016