| Message ID | 1575012326-51324-2-git-send-email-pannengyuan@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [V3,1/2] block/nbd: extract the common cleanup code | expand |
It's just a memory leak, but it's a regression in 4.2. Should we take it into 4.2? 29.11.2019 10:25, pannengyuan@huawei.com wrote: > 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> May add: Fixes: 8f071c9db506e03ab (I found it just by git log -p, could you please check it by your reproduce?) Ohh, that's my commit, I'm sorry. If you discovered this commit by yourself, and added Fixes: tag and myself to CC, I'd have reviewed it a lot earlier.. > --- > Changes v2 to v1: > - add a new function to do the common cleanups (suggested by Stefano > Garzarella). > --- > Changes v3 to v2: > - split in two patches(suggested by Stefano Garzarella) > --- > block/nbd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/nbd.c b/block/nbd.c > index 5805979..09d6925 100644 > --- a/block/nbd.c > +++ b/block/nbd.c > @@ -1889,6 +1889,7 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags, > > ret = nbd_client_connect(bs, errp); > if (ret < 0) { > + nbd_free_bdrvstate_prop(s); > return ret; > } > /* successfully connected */ > Thanks for fixing! Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote: > It's just a memory leak, but it's a regression in 4.2. > > Should we take it into 4.2? Sorry, I was on holiday and then jury service, so I missed any chance at getting this into -rc3. The memory leak only happens on failure, and you'd have to be pretty desperate to purposefully attempt to open a lot of NBD devices where you know you'll get a failure just to trigger enough of a leak to cause the OOM-killer to target qemu. So I'm fine if this is deferred to 5.0, and just cc's qemu-stable (now done). I'll queue this through my NBD tree for 5.0. > > > 29.11.2019 10:25, pannengyuan@huawei.com wrote: >> From: PanNengyuan <pannengyuan@huawei.com> >> >> Reported-by: Euler Robot <euler.robot@huawei.com> >> Signed-off-by: PanNengyuan <pannengyuan@huawei.com> I'm not one to tell you that your name is written incorrectly, but it does look odd to have a single word rather than a space between two capitalized portions. If that's really how you want your S-o-b and authorship to appear, I'm happy to preserve it; but you may want to consider updating your git settings, and posting a v4 with an updated spelling if you would prefer something different. (It is also acceptable to use UTF-8 characters; some people like listing an S-o-b in both native characters and a Westernized variant). > > May add: > > Fixes: 8f071c9db506e03ab Yes, information like that helps in deciding how long the problem has been present (in this case, it is indeed a regression added in 4.2, even if minor in nature).
On 12/3/19 12:54 PM, Eric Blake wrote: > On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote: >> It's just a memory leak, but it's a regression in 4.2. >> >> Should we take it into 4.2? > > Sorry, I was on holiday and then jury service, so I missed any chance at > getting this into -rc3. The memory leak only happens on failure, and > you'd have to be pretty desperate to purposefully attempt to open a lot > of NBD devices where you know you'll get a failure just to trigger > enough of a leak to cause the OOM-killer to target qemu. So I'm fine if > this is deferred to 5.0, and just cc's qemu-stable (now done). > > I'll queue this through my NBD tree for 5.0. Actually, given the review comments on 1/2, we'll probably be better off with a v4 for the series.
On 2019/12/4 2:54, Eric Blake wrote: > On 12/3/19 11:52 AM, Vladimir Sementsov-Ogievskiy wrote: >> It's just a memory leak, but it's a regression in 4.2. >> >> Should we take it into 4.2? > > Sorry, I was on holiday and then jury service, so I missed any chance at > getting this into -rc3. The memory leak only happens on failure, and > you'd have to be pretty desperate to purposefully attempt to open a lot > of NBD devices where you know you'll get a failure just to trigger > enough of a leak to cause the OOM-killer to target qemu. So I'm fine if > this is deferred to 5.0, and just cc's qemu-stable (now done). > > I'll queue this through my NBD tree for 5.0. > >> >> >> 29.11.2019 10:25, pannengyuan@huawei.com wrote: >>> From: PanNengyuan <pannengyuan@huawei.com> > >>> >>> Reported-by: Euler Robot <euler.robot@huawei.com> >>> Signed-off-by: PanNengyuan <pannengyuan@huawei.com> > > I'm not one to tell you that your name is written incorrectly, but it > does look odd to have a single word rather than a space between two > capitalized portions. If that's really how you want your S-o-b and > authorship to appear, I'm happy to preserve it; but you may want to > consider updating your git settings, and posting a v4 with an updated > spelling if you would prefer something different. (It is also > acceptable to use UTF-8 characters; some people like listing an S-o-b in > both native characters and a Westernized variant). > Thanks for your advice, I will update my git settings. >> >> May add: >> >> Fixes: 8f071c9db506e03ab > > Yes, information like that helps in deciding how long the problem has > been present (in this case, it is indeed a regression added in 4.2, even > if minor in nature). > ok, I will add it next time.
diff --git a/block/nbd.c b/block/nbd.c index 5805979..09d6925 100644 --- a/block/nbd.c +++ b/block/nbd.c @@ -1889,6 +1889,7 @@ static int nbd_open(BlockDriverState *bs, QDict *options, int flags, ret = nbd_client_connect(bs, errp); if (ret < 0) { + nbd_free_bdrvstate_prop(s); return ret; } /* successfully connected */