dm-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: lixiaokeng <lixiaokeng@huawei.com>
To: Martin Wilck <mwilck@suse.com>,
	Christophe Varoqui <christophe.varoqui@opensvc.com>,
	Benjamin Marzinski <bmarzins@redhat.com>,
	dm-devel mailing list <dm-devel@redhat.com>
Cc: linfeilong <linfeilong@huawei.com>,
	"liuzhiqiang \(I\)" <liuzhiqiang26@huawei.com>
Subject: Re: [dm-devel] [PATCH] libmultipath: fix memory leaks in coalesce_paths
Date: Mon, 19 Oct 2020 18:17:02 +0800	[thread overview]
Message-ID: <4aca3d1d-eade-8fbc-04f2-6b8f17382d1b@huawei.com> (raw)
In-Reply-To: <757aa2249e036cf2c659bedd6c9fe748af3c0894.camel@suse.com>



On 2020/10/17 3:51, Martin Wilck wrote:
> On Fri, 2020-10-16 at 14:23 +0800, lixiaokeng wrote:
>> When multipath -F are executed firstly and multipath -v2 or
>> -d are executed later, asan will warn memory leaks. The
>> reason is that the mpp allocated in coalesce_paths isn't
>> freed. Here we add newmp in configure(multipath) to store
>> mpp and free it.
>>
>> Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
>> Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
>> Signed-off-by: Linfeilong <linfeilong@huawei.com>
> 
> Besides what Ben noted already, I think you shouldn't force callers to
> pass a non-NULL "newmp". The tricky part is to make sure that paths
> aren't handled repeatedly in the CMD_DRY_RUN case. Currently pp->mpp !=
> NULL is the condition used by coalesce_paths() to check if a path has
> already been dealt with; if you simply call remove_map(), that won't
> work any more. I suppose you realized that, and that's why you
> introduced the non-NULL newmp in multipath (you should have mentioned
> that in the changelog message).
> 
> I suggest to have callers pass a "vector *pnewmp" instead of "vector
> newmp", always allocate newmp in coalesce_paths(), and upon return,
> either free newmp, or assign it to the pointer passed by the caller:
> 
>      if (pnewmp)
> 	    *pnewmp = newmp;
>      else
>             free_multipathvec(newmp, KEEP_PATHS);
> 
> Regards,
> Martin
>
Hi Martin,
   Thanks for your review. It is a great idea with your suggestion.
I think it's better that callers pass a "vector mpvec" instead of
"vector newmp", either copy mpvec to newmp or allocate newmp at the
beginning of coalesce_paths, and free newmp or not at the end:

int coalesce_paths (struct vectors *vecs, vector mpvec, char *refwwid,
		    int force_reload, enum mpath_cmds cmd)
	......

 	if (mpvec)
		newmp = mpvec;
	else
		newmp = vector_alloc();
	if (!newmp) {
		condlog(0, "can not allocate newmp");
		return ret;
	}
	......
	
 	if (!mpvec)
		free_multipathvec(newmp, KEEP_PATHS);

About conflict, can you give me the url of the code with your
patchset? If I just change coalease_paths, will it have some
conflicts?

Regards,
Lixiaokeng

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


      reply	other threads:[~2020-10-19 10:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16  6:23 [dm-devel] [PATCH] libmultipath: fix memory leaks in coalesce_paths lixiaokeng
2020-10-16 17:31 ` Benjamin Marzinski
2020-10-16 19:51 ` Martin Wilck
2020-10-19 10:17   ` lixiaokeng [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=4aca3d1d-eade-8fbc-04f2-6b8f17382d1b@huawei.com \
    --to=lixiaokeng@huawei.com \
    --cc=bmarzins@redhat.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@redhat.com \
    --cc=linfeilong@huawei.com \
    --cc=liuzhiqiang26@huawei.com \
    --cc=mwilck@suse.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).