From mboxrd@z Thu Jan 1 00:00:00 1970 From: lixiaokeng Subject: Re: [PATCH 5/5] libmultipath fix daemon memory leak in disassemble_map Date: Wed, 19 Aug 2020 16:45:23 +0800 Message-ID: <8dcc835f-5cda-89d5-acb6-67af1fe7bb78@huawei.com> References: <5ef5f58e-3a27-8959-3abb-4b4c401cc309@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-GB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Martin Wilck , Benjamin Marzinski , Christophe Varoqui Cc: linfeilong@huawei.com, dm-devel mailing list , liuzhiqiang26@huawei.com List-Id: dm-devel.ids Hi Martin, Thanks for your answers. I understand the relationship between branches. On 2020/8/19 16:26, Martin Wilck wrote: > Hello lixiaokeng, > > Thanks again for your contribution. > > On Wed, 2020-08-19 at 09:50 +0800, lixiaokeng wrote: >> >> If checking is_deamon is deleted, there are many other things need be >> done like in >> https://www.redhat.com/archives/dm-devel/2020-July/msg00245.html. And >> this >> branch develops from 0.8.3 but upstream_queue is mainline which >> develops from >> 0.8.4. > > This is a misunderstanding. My upstream-queue branch is *not* mainline. > Mainline is http://git.opensvc.com/multipath-tools/.git. Also, my > entire patch series (link above) was based on upstream-queue, which in > turn was based on 0.8.4, not 0.8.3. > > As the name says, "upstream-queue" represents the queue of pending > patches which have at least one positive review (and no negative ones). > The intention is 1. to provide an overview for myself and other > interested parties, and 2. to simplify matters for the actual > maintainer, Christophe, when he applies patches onto mainline. > > My patch series changes the same code path as this one, and I think it > solves the same issue, albeit differently. Most of my series has > meanwhile been positively reviewed by Ben, and the remaining open > issues are in other parts of the series. I'll hopefully be able to push > it to upstream-queue soon. IMO it makes little sense to push changes to > upstream-queue which are going to be removed again when my series is > applied (I don't intend to start using merge operations in this > branch). > > Christophe is on the recipients list of your patch. He may of course > decide to apply your patch before my series, in which case I'll have to > rebase mine. But he'll probably have other prior patches to look at > first before he gets down to this one. > > Regards, > Martin >