From: Pan Nengyuan <pannengyuan@huawei.com>
To: John Snow <jsnow@redhat.com>, <pbonzini@redhat.com>, <fam@euphon.net>
Cc: zhang.zhanghailiang@huawei.com, qemu-devel@nongnu.org,
Qemu-block <qemu-block@nongnu.org>,
Euler Robot <euler.robot@huawei.com>
Subject: Re: [PATCH] scsi-disk: define props in scsi_block_disk to avoid memleaks
Date: Tue, 14 Jan 2020 09:45:53 +0800 [thread overview]
Message-ID: <04ae5085-e40c-a700-a29c-4205e3d9cef5@huawei.com> (raw)
In-Reply-To: <9292c330-0ab5-9a96-4e1b-2cb9ccc4cc33@redhat.com>
On 1/14/2020 6:56 AM, John Snow wrote:
> CC qemu-block
>
> On 1/13/20 1:20 AM, pannengyuan@huawei.com wrote:
>> From: Pan Nengyuan <pannengyuan@huawei.com>
>>
>> scsi_block_realize() use scsi_realize() to init some props, but
>> these props is not defined in scsi_block_disk_properties, so they will
>> not be freed.
>>
>> This patch defines these prop in scsi_block_disk_properties and aslo
>> calls scsi_unrealize to avoid memleaks, the leak stack as
>> follow(it's easy to reproduce by attaching/detaching scsi-block-disks):
>>
>> =================================================================
>> ==qemu-system-x86_64==32195==ERROR: LeakSanitizer: detected memory leaks
>>
>> Direct leak of 57 byte(s) in 3 object(s) allocated from:
>> #0 0x7f19f8bed768 (/lib64/libasan.so.5+0xef768) ??:?
>> #1 0x7f19f64d9445 (/lib64/libglib-2.0.so.0+0x52445) ??:?
>> #2 0x7f19f64f2d92 (/lib64/libglib-2.0.so.0+0x6bd92) ??:?
>> #3 0x55975366e596 (qemu-system-x86_64+0x35c0596) /mnt/sdb/qemu/hw/scsi/scsi-disk.c:2399
>> #4 0x559753671201 (emu-system-x86_64+0x35c3201) /mnt/sdb/qemu/hw/scsi/scsi-disk.c:2681
>> #5 0x559753687e3e (qemu-system-x86_64+0x35d9e3e) /mnt/sdb/qemu/hw/scsi/scsi-bus.c:58
>> #6 0x55975368ac44 (qemu-system-x86_64+0x35dcc44) /mnt/sdb/qemu/hw/scsi/scsi-bus.c:216
>> #7 0x5597532a7840 (qemu-system-x86_64+0x31f9840) /mnt/sdb/qemu/hw/core/qdev.c:876
>>
>> Direct leak of 15 byte(s) in 3 object(s) allocated from:
>> #0 0x7f19f8bed768 (/lib64/libasan.so.5+0xef768) ??:?
>> #1 0x7f19f64d9445 (/lib64/libglib-2.0.so.0+0x52445) ??:?
>> #2 0x7f19f64f2d92 (/lib64/libglib-2.0.so.0+0x6bd92) ??:?
>> #3 0x55975366e06f (qemu-system-x86_64+0x35c006f) /mnt/sdb/qemu/hw/scsi/scsi-disk.c:2388
>> #4 0x559753671201 (qemu-system-x86_64+0x35c3201) /mnt/sdb/qemu/hw/scsi/scsi-disk.c:2681
>> #5 0x559753687e3e (qemu-system-x86_64+0x35d9e3e) /mnt/sdb/qemu/hw/scsi/scsi-bus.c:58
>> #6 0x55975368ac44 (qemu-system-x86_64+0x35dcc44) /mnt/sdb/qemu/hw/scsi/scsi-bus.c:216
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
>> ---
>> hw/scsi/scsi-disk.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
>> index e44c61eeb4..caec99ae20 100644
>> --- a/hw/scsi/scsi-disk.c
>> +++ b/hw/scsi/scsi-disk.c
>> @@ -2981,7 +2981,6 @@ static const TypeInfo scsi_disk_base_info = {
>> };
>>
>> #define DEFINE_SCSI_DISK_PROPERTIES() \
>> - DEFINE_PROP_DRIVE_IOTHREAD("drive", SCSIDiskState, qdev.conf.blk), \
>> DEFINE_BLOCK_PROPERTIES_BASE(SCSIDiskState, qdev.conf), \
>> DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf), \
>> DEFINE_PROP_STRING("ver", SCSIDiskState, version), \
>> @@ -2993,6 +2992,7 @@ static const TypeInfo scsi_disk_base_info = {
>>
>> static Property scsi_hd_properties[] = {
>> DEFINE_SCSI_DISK_PROPERTIES(),
>> + DEFINE_PROP_DRIVE_IOTHREAD("drive", SCSIDiskState, qdev.conf.blk),
>> DEFINE_PROP_BIT("removable", SCSIDiskState, features,
>> SCSI_DISK_F_REMOVABLE, false),
>> DEFINE_PROP_BIT("dpofua", SCSIDiskState, features,
>> @@ -3048,6 +3048,7 @@ static const TypeInfo scsi_hd_info = {
>>
>
> Does changing around the property order here break migration?
Yes, it will change the order. I'm not sure what it will affect.
So I think I should move 'drive' to the front to keep the original order.
I will change it in next version.
Thanks.
>
>> static Property scsi_cd_properties[] = {
>> DEFINE_SCSI_DISK_PROPERTIES(),
>> + DEFINE_PROP_DRIVE_IOTHREAD("drive", SCSIDiskState, qdev.conf.blk),
>> DEFINE_PROP_UINT64("wwn", SCSIDiskState, qdev.wwn, 0),
>> DEFINE_PROP_UINT64("port_wwn", SCSIDiskState, qdev.port_wwn, 0),
>> DEFINE_PROP_UINT16("port_index", SCSIDiskState, port_index, 0),
>> @@ -3079,9 +3080,8 @@ static const TypeInfo scsi_cd_info = {
>>
>> #ifdef __linux__
>> static Property scsi_block_properties[] = {
>> - DEFINE_BLOCK_ERROR_PROPERTIES(SCSIDiskState, qdev.conf), \
>> + DEFINE_SCSI_DISK_PROPERTIES(),
>> DEFINE_PROP_DRIVE("drive", SCSIDiskState, qdev.conf.blk),
>> - DEFINE_PROP_BOOL("share-rw", SCSIDiskState, qdev.conf.share_rw, false),
>> DEFINE_PROP_UINT16("rotation_rate", SCSIDiskState, rotation_rate, 0),
>> DEFINE_PROP_UINT64("max_unmap_size", SCSIDiskState, max_unmap_size,
>> DEFAULT_MAX_UNMAP_SIZE),
>> @@ -3099,6 +3099,7 @@ static void scsi_block_class_initfn(ObjectClass *klass, void *data)
>> SCSIDiskClass *sdc = SCSI_DISK_BASE_CLASS(klass);
>>
>> sc->realize = scsi_block_realize;
>> + sc->unrealize = scsi_unrealize;
>> sc->alloc_req = scsi_block_new_request;
>> sc->parse_cdb = scsi_block_parse_cdb;
>> sdc->dma_readv = scsi_block_dma_readv;
>> @@ -3119,6 +3120,7 @@ static const TypeInfo scsi_block_info = {
>>
>> static Property scsi_disk_properties[] = {
>> DEFINE_SCSI_DISK_PROPERTIES(),
>> + DEFINE_PROP_DRIVE_IOTHREAD("drive", SCSIDiskState, qdev.conf.blk),
>> DEFINE_PROP_BIT("removable", SCSIDiskState, features,
>> SCSI_DISK_F_REMOVABLE, false),
>> DEFINE_PROP_BIT("dpofua", SCSIDiskState, features,
>>
>
prev parent reply other threads:[~2020-01-14 1:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 6:20 [PATCH] scsi-disk: define props in scsi_block_disk to avoid memleaks pannengyuan
2020-01-13 22:56 ` John Snow
2020-01-14 1:45 ` Pan Nengyuan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04ae5085-e40c-a700-a29c-4205e3d9cef5@huawei.com \
--to=pannengyuan@huawei.com \
--cc=euler.robot@huawei.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).