| Message ID | 1574930410-43468-1-git-send-email-pannengyuan@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block/nbd: fix memory leak in nbd_open() | expand |
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
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 > > > . >
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 > > > > > > . > > > --
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 >>> >>> >>> . >>> >> >
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 */