1. Patchew
  2. QEMU
  3. View series

[PATCH] block/nbd: fix memory leak in nbd_open()

pannengyuan@huawei.com posted 1 patch 4 years, 5 months ago
Test FreeBSD passed
Test docker-mingw@fedora passed
Test docker-clang@ubuntu passed
Test docker-quick@centos7 passed
Test asan passed
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/1574930410-43468-1-git-send-email-pannengyuan@huawei.com
Maintainers: Kevin Wolf <kwolf@redhat.com>, Eric Blake <eblake@redhat.com>, Max Reitz <mreitz@redhat.com>
There is a newer version of this series
block/nbd.c | 5 +++++
1 file changed, 5 insertions(+)
[PATCH] block/nbd: fix memory leak in nbd_open()
Posted by pannengyuan@huawei.com 4 years, 5 months ago 
From: PanNengyuan <pannengyuan@huawei.com>

In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to reproduce:

1. run qemu-iotests as follow and check the result with asan:
    ./check -raw 143

Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
    #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
    #2 0x56281dab4642 in qobject_input_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
    #3 0x56281dab1a04 in visit_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
    #4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
    #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
    #6 0x56281da8062f in nbd_process_options  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
    #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Direct leak of 15 byte(s) in 1 object(s) allocated from:
    #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
    #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
    #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
    #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
    #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
    #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
    #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
    #3 0x56281dab41a3 in qobject_input_type_str_keyval   /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
    #4 0x56281dab2ee9 in visit_type_str   /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
    #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  qapi/qapi-visit-sockets.c:141
    #6 0x56281dad17b6 in visit_type_SocketAddress_members      qapi/qapi-visit-sockets.c:366
    #7 0x56281dad186a in visit_type_SocketAddress     qapi/qapi-visit-sockets.c:393
    #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
    #9 0x56281da8062f in nbd_process_options   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
    #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
---
 block/nbd.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/block/nbd.c b/block/nbd.c
index 1239761..bc40a25 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
 
     ret = nbd_client_connect(bs, errp);
     if (ret < 0) {
+        object_unref(OBJECT(s->tlscreds));
+        qapi_free_SocketAddress(s->saddr);
+        g_free(s->export);
+        g_free(s->tlscredsid);
+        g_free(s->x_dirty_bitmap);
         return ret;
     }
     /* successfully connected */
-- 
2.7.2.windows.1
Re: [PATCH] block/nbd: fix memory leak in nbd_open()
Posted by Stefano Garzarella 4 years, 5 months ago 
On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:

Hi,
I don't know nbd code very well, the patch LGTM, but just a comment
below:

> From: PanNengyuan <pannengyuan@huawei.com>
> 
> In currently implementation there will be a memory leak when
> nbd_client_connect() returns error status. Here is an easy way to reproduce:
> 
> 1. run qemu-iotests as follow and check the result with asan:
>     ./check -raw 143
> 
> Following is the asan output backtrack:
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>     #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>     #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
>     #2 0x56281dab4642 in qobject_input_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>     #3 0x56281dab1a04 in visit_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>     #4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
>     #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>     #6 0x56281da8062f in nbd_process_options  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>     #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>     #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>     #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
>     #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>     #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>     #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>     #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>     #3 0x56281dab41a3 in qobject_input_type_str_keyval   /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>     #4 0x56281dab2ee9 in visit_type_str   /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>     #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  qapi/qapi-visit-sockets.c:141
>     #6 0x56281dad17b6 in visit_type_SocketAddress_members      qapi/qapi-visit-sockets.c:366
>     #7 0x56281dad186a in visit_type_SocketAddress     qapi/qapi-visit-sockets.c:393
>     #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>     #9 0x56281da8062f in nbd_process_options   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>     #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
> ---
>  block/nbd.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/block/nbd.c b/block/nbd.c
> index 1239761..bc40a25 100644
> --- a/block/nbd.c
> +++ b/block/nbd.c
> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>  
>      ret = nbd_client_connect(bs, errp);
>      if (ret < 0) {
> +        object_unref(OBJECT(s->tlscreds));
> +        qapi_free_SocketAddress(s->saddr);
> +        g_free(s->export);
> +        g_free(s->tlscredsid);
> +        g_free(s->x_dirty_bitmap);

Since with this patch we are doing these cleanups in 3 places (here,
nbd_close(), and nbd_process_options()), should be better to add a new
function to do these cleanups?

Maybe I'd create a series adding a patch before this one, implementing this
new function, and change this patch calling it.

Thanks,
Stefano
Re: [PATCH] block/nbd: fix memory leak in nbd_open()
Posted by pannengyuan 4 years, 5 months ago 
Hi,
I think it's a better way, you can implement this new function before
this patch.

Thanks.

On 2019/11/28 17:01, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
> 
> Hi,
> I don't know nbd code very well, the patch LGTM, but just a comment
> below:
> 
>> From: PanNengyuan <pannengyuan@huawei.com>
>>
>> In currently implementation there will be a memory leak when
>> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>>
>> 1. run qemu-iotests as follow and check the result with asan:
>>     ./check -raw 143
>>
>> Following is the asan output backtrack:
>> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>>     #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>>     #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
>>     #2 0x56281dab4642 in qobject_input_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>>     #3 0x56281dab1a04 in visit_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>>     #4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
>>     #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>     #6 0x56281da8062f in nbd_process_options  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>     #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>     #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>     #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>     #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>>     #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>     #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>     #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>     #3 0x56281dab41a3 in qobject_input_type_str_keyval   /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>>     #4 0x56281dab2ee9 in visit_type_str   /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>>     #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  qapi/qapi-visit-sockets.c:141
>>     #6 0x56281dad17b6 in visit_type_SocketAddress_members      qapi/qapi-visit-sockets.c:366
>>     #7 0x56281dad186a in visit_type_SocketAddress     qapi/qapi-visit-sockets.c:393
>>     #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>     #9 0x56281da8062f in nbd_process_options   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>     #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
>> ---
>>  block/nbd.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/block/nbd.c b/block/nbd.c
>> index 1239761..bc40a25 100644
>> --- a/block/nbd.c
>> +++ b/block/nbd.c
>> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>>  
>>      ret = nbd_client_connect(bs, errp);
>>      if (ret < 0) {
>> +        object_unref(OBJECT(s->tlscreds));
>> +        qapi_free_SocketAddress(s->saddr);
>> +        g_free(s->export);
>> +        g_free(s->tlscredsid);
>> +        g_free(s->x_dirty_bitmap);
> 
> Since with this patch we are doing these cleanups in 3 places (here,
> nbd_close(), and nbd_process_options()), should be better to add a new
> function to do these cleanups?
> 
> Maybe I'd create a series adding a patch before this one, implementing this
> new function, and change this patch calling it.
> 
> Thanks,
> Stefano
> 
> 
> .
>
Re: [PATCH] block/nbd: fix memory leak in nbd_open()
Posted by Stefano Garzarella 4 years, 5 months ago 
On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
> Hi,
> I think it's a better way, you can implement this new function before
> this patch.

If you want to do it, so you can send everything together, for me there's
no problem, it was just a suggestion.

If you don't have time, I can do it.

Cheers,
Stefano

> 
> Thanks.
> 
> On 2019/11/28 17:01, Stefano Garzarella wrote:
> > On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
> > 
> > Hi,
> > I don't know nbd code very well, the patch LGTM, but just a comment
> > below:
> > 
> >> From: PanNengyuan <pannengyuan@huawei.com>
> >>
> >> In currently implementation there will be a memory leak when
> >> nbd_client_connect() returns error status. Here is an easy way to reproduce:
> >>
> >> 1. run qemu-iotests as follow and check the result with asan:
> >>     ./check -raw 143
> >>
> >> Following is the asan output backtrack:
> >> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> >>     #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> >>     #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
> >>     #2 0x56281dab4642 in qobject_input_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> >>     #3 0x56281dab1a04 in visit_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> >>     #4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
> >>     #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >>     #6 0x56281da8062f in nbd_process_options  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >>     #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> >>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >>     #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >>     #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >>     #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> >>     #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> >>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >>     #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >>     #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >>     #3 0x56281dab41a3 in qobject_input_type_str_keyval   /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> >>     #4 0x56281dab2ee9 in visit_type_str   /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> >>     #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  qapi/qapi-visit-sockets.c:141
> >>     #6 0x56281dad17b6 in visit_type_SocketAddress_members      qapi/qapi-visit-sockets.c:366
> >>     #7 0x56281dad186a in visit_type_SocketAddress     qapi/qapi-visit-sockets.c:393
> >>     #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >>     #9 0x56281da8062f in nbd_process_options   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >>     #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Reported-by: Euler Robot <euler.robot@huawei.com>
> >> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
> >> ---
> >>  block/nbd.c | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/block/nbd.c b/block/nbd.c
> >> index 1239761..bc40a25 100644
> >> --- a/block/nbd.c
> >> +++ b/block/nbd.c
> >> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
> >>  
> >>      ret = nbd_client_connect(bs, errp);
> >>      if (ret < 0) {
> >> +        object_unref(OBJECT(s->tlscreds));
> >> +        qapi_free_SocketAddress(s->saddr);
> >> +        g_free(s->export);
> >> +        g_free(s->tlscredsid);
> >> +        g_free(s->x_dirty_bitmap);
> > 
> > Since with this patch we are doing these cleanups in 3 places (here,
> > nbd_close(), and nbd_process_options()), should be better to add a new
> > function to do these cleanups?
> > 
> > Maybe I'd create a series adding a patch before this one, implementing this
> > new function, and change this patch calling it.
> > 
> > Thanks,
> > Stefano
> > 
> > 
> > .
> > 
> 

--
Re: [PATCH] block/nbd: fix memory leak in nbd_open()
Posted by pannengyuan 4 years, 5 months ago 
Thanks for you suggestion, I'd be glad to do it, I will send a new
version later.

Cheers.

On 2019/11/28 18:41, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
>> Hi,
>> I think it's a better way, you can implement this new function before
>> this patch.
> 
> If you want to do it, so you can send everything together, for me there's
> no problem, it was just a suggestion.
> 
> If you don't have time, I can do it.
> 
> Cheers,
> Stefano
> 
>>
>> Thanks.
>>
>> On 2019/11/28 17:01, Stefano Garzarella wrote:
>>> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengyuan@huawei.com wrote:
>>>
>>> Hi,
>>> I don't know nbd code very well, the patch LGTM, but just a comment
>>> below:
>>>
>>>> From: PanNengyuan <pannengyuan@huawei.com>
>>>>
>>>> In currently implementation there will be a memory leak when
>>>> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>>>>
>>>> 1. run qemu-iotests as follow and check the result with asan:
>>>>     ./check -raw 143
>>>>
>>>> Following is the asan output backtrack:
>>>> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>>>>     #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>>>>     #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
>>>>     #2 0x56281dab4642 in qobject_input_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>>>>     #3 0x56281dab1a04 in visit_start_struct  /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>>>>     #4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
>>>>     #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>>>     #6 0x56281da8062f in nbd_process_options  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>>>     #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>>>>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>>>     #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>>>     #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>>>     #3 0x56281da804ac in nbd_process_options /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>>>>     #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>>>>     #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>>>>     #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>>>>     #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>>>>     #3 0x56281dab41a3 in qobject_input_type_str_keyval   /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>>>>     #4 0x56281dab2ee9 in visit_type_str   /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>>>>     #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  qapi/qapi-visit-sockets.c:141
>>>>     #6 0x56281dad17b6 in visit_type_SocketAddress_members      qapi/qapi-visit-sockets.c:366
>>>>     #7 0x56281dad186a in visit_type_SocketAddress     qapi/qapi-visit-sockets.c:393
>>>>     #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>>>>     #9 0x56281da8062f in nbd_process_options   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>>>>     #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>>>
>>>> Reported-by: Euler Robot <euler.robot@huawei.com>
>>>> Signed-off-by: PanNengyuan <pannengyuan@huawei.com>
>>>> ---
>>>>  block/nbd.c | 5 +++++
>>>>  1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/block/nbd.c b/block/nbd.c
>>>> index 1239761..bc40a25 100644
>>>> --- a/block/nbd.c
>>>> +++ b/block/nbd.c
>>>> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags,
>>>>  
>>>>      ret = nbd_client_connect(bs, errp);
>>>>      if (ret < 0) {
>>>> +        object_unref(OBJECT(s->tlscreds));
>>>> +        qapi_free_SocketAddress(s->saddr);
>>>> +        g_free(s->export);
>>>> +        g_free(s->tlscredsid);
>>>> +        g_free(s->x_dirty_bitmap);
>>>
>>> Since with this patch we are doing these cleanups in 3 places (here,
>>> nbd_close(), and nbd_process_options()), should be better to add a new
>>> function to do these cleanups?
>>>
>>> Maybe I'd create a series adding a patch before this one, implementing this
>>> new function, and change this patch calling it.
>>>
>>> Thanks,
>>> Stefano
>>>
>>>
>>> .
>>>
>>
>

Patchew 2.1-devel-0870f84

© 2016 - 2024 Red Hat, Inc.