Re: [libvirt] [RFC] support vhost-user-scsi configuration

2023-04-18 Thread wangjian
On 2023/4/18 21:50, wangjian (AN) wrote: > > On 4/15/23 15:48, wangjian (AN) wrote: >> Hi Guys, >> >> >> >> Currently qemu and spdk already support vhost-user-scsi, but there is >> no vhost-user-scsi configuration in libvirt. >> >> We h

[libvirt] [RFC] support vhost-user-scsi configuration

2023-04-15 Thread wangjian (AN)
Hi Guys, Currently qemu and spdk already support vhost-user-scsi, but there is no vhost-user-scsi configuration in libvirt. We hope that libvirt supports the following configurations to facilitate docking with qemu. The usage in qemu like this: -chardev

Re: [PATCH] serialize access pci_get_strings function with a mutex

2021-03-26 Thread wangjian (AN)
Ok. I agree. On 2021/3/26 17:10, Michal Privoznik wrote: > There's no need to CC random developers - we are subscribed to the list. > > On 3/26/21 4:21 AM, wangjian wrote:> serialize access pci_get_strings > function with a mutex.> > nodedev-init thread: >> n

[PATCH] serialize access pci_get_strings function with a mutex

2021-03-25 Thread wangjian
eads of libvirt call the pci_get_strings function provided by libpaciaccess at the same time. It will appear that for the same address, realloc a large space first, and then realloc a small space, which triggers the 'invalid next size' of realloc, leading to the thread core. Signed-off-by: WangJian --

RE: [PATCH] virtlogd: solve some memory leaks

2020-06-17 Thread wangjian (AN)
virtual machines, kill -9 virtlogd, libvirtd, etc. -Original Message- From: Michal Privoznik [mailto:mpriv...@redhat.com] Sent: Tuesday, June 16, 2020 9:58 PM To: wangjian (AN) Cc: libvir-list@redhat.com Subject: Re: [PATCH] virtlogd: solve some memory leaks On 6/16/20 8:26 AM, wangjian

[PATCH] virtlogd: solve some memory leaks

2020-06-16 Thread wangjian
We used asan to find some memory leaks in virtlogd. In the virThreadPoolFree function, When job->data is of type virNetServerJobPtr, the following memory leak problem exists. 1. job->data is not released Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x7f14ab932560 in calloc