[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRIYsNCMmKrPfRlF@kroah.com>
Date: Tue, 10 Aug 2021 08:12:00 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Dongliang Mu <mudongliangabcd@...il.com>
Cc: Samuel Iglesias Gonsalvez <siglesias@...lia.com>,
Jens Taprogge <jens.taprogge@...rogge.org>,
Randy Dunlap <rdunlap@...radead.org>,
Aditya Srivastava <yashsri421@...il.com>,
Lv Yunlong <lyl2019@...l.ustc.edu.cn>,
industrypack-devel@...ts.sourceforge.net,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] ipack: tpci200: fix many double free issues in
tpci200_pci_probe
On Tue, Aug 10, 2021 at 07:41:55AM +0800, Dongliang Mu wrote:
> On Tue, Aug 10, 2021 at 7:08 AM Dongliang Mu <mudongliangabcd@...il.com> wrote:
> >
> > On Mon, Aug 9, 2021 at 11:32 PM Greg Kroah-Hartman
> > <gregkh@...uxfoundation.org> wrote:
> > >
> > > On Mon, Aug 09, 2021 at 10:30:26PM +0800, Dongliang Mu wrote:
> > > > The function tpci200_register called by tpci200_install and
> > > > tpci200_unregister called by tpci200_uninstall are in pair. However,
> > > > tpci200_unregister has some cleanup operations not in the
> > > > tpci200_register. So the error handling code of tpci200_pci_probe has
> > > > many different double free issues.
> > > >
> > > > Fix this problem by moving those cleanup operations out of
> > > > tpci200_unregister, into tpci200_pci_remove and reverting
> > > > the previous commit 9272e5d0028d ("ipack/carriers/tpci200:
> > > > Fix a double free in tpci200_pci_probe").
> > > >
> > > > Reported-by: Dongliang Mu <mudongliangabcd@...il.com>
> > > > Fixes: 9272e5d0028d ("ipack/carriers/tpci200: Fix a double free in tpci200_pci_probe")
> > > > Signed-off-by: Dongliang Mu <mudongliangabcd@...il.com>
> > > > ---
> > > > v1->v2: revise PATCH 2/3, 3/3, not depending on PATCH 1/3; move the
> > > > location change of tpci_unregister into one separate patch;
> > >
> > > Also needs to go to the stable trees, right?
> >
> > Yes, this needs to go to the stable trees.
>
> Hi gregkh,
>
> Let me clarify more. In my series, PATCH 3/4 4/4 depends on PATCH 1/4
> and PATCH 2/4. And also PATCH 2/4 depends on PATCH 1/4 as they are
> closely related.
>
> But from your reply, the last 2 patches should not depend on the first
> 2 patches. I don't quite understand as I don't send some patch series
> before. For a patch series, the latter ones should depend on the
> former ones, right? If I have any misunderstanding, please let me
> know.
Yes, they can depend on previous patches, but if some patches are to be
merged today for 5.14-final, and others later for 5.15-rc1, then ideally
they will be separate series of changes as those go to two different
branches in my tree at the moment.
> BTW, PATCH 3/4 has some compilation issues. I will fix it in the next version.
As you haven't even tested these, I'm really hesitant to take them at
all.
Please just send the first two patches, fixed up, as a series after you
have tested them, and then after they are merged into Linus's tree, you
can send the cleanup patches, as they are just "nice" to have.
thanks,
greg k-h
Powered by blists - more mailing lists