ACK/Cmnt: [B][D][E][F][SRU][PATCH 0/1] Fix for CVE-2019-19082

Po-Hsu Lin po-hsu.lin at canonical.com
Thu Jan 2 11:39:48 UTC 2020


Hi Kleber,

thanks for the explanation, do you have a suggested workflow on this?
I used to run git cherry-pick command under different trees, now I am
doing this with:
  1. git format-patch SHA1 -1 in Linus' tree
  2. Try to apply it to our tree with git am -C2
  3. Reset HEAD^ in our tree, and run git cherry-pick SHA1 to
determine if it can be called as a cherry-pick

I tried the kteam-tools/stable/cherry-pick.sh script, but it can't
tell if it should be considered as a backport.

Thanks
Sam


On Tue, Dec 17, 2019 at 4:55 PM Kleber Souza <kleber.souza at canonical.com> wrote:
>
> On 09.12.19 11:46, Po-Hsu Lin wrote:
> > Hi Connor,
> >
> > Thanks for reviewing this, as this patch commit SHA1 can be applied
> > with git cherry-pick command, maybe this should not be considered as a
> > backport?
> > I think there were some discussions for this kind of fuzzy-appy thing
> > before, but IIRC that's for can a generated patch be applied to all
> > the series.
>
> Hi Sam,
>
> Our definition of "cherry-pick" is a bit different from the one used
> by git. For us to consider a patch to be "cherry picked" from a given
> SHA1, when you generate a patch from the original tree (e.g. Linus'
> tree) using "git format-patch" we need to be able to apply the
> resulting patch to the target repo with "git am". Sometimes there is
> only a small difference in the context and a patch can be applied
> using "git am -C2", in that case the submitter just needs to state in
> the cover letter that "-C2" is needed.
>
> If that doesn't work, and even if we need to do a "git cherry-pick"
> first on the target repo and generate the patch from there, then
> it's consider to be "backported from".
>
>
> Thanks,
> Kleber
>
>
> >
> > Cheers
> > Sam
> >
> >
> > On Sat, Dec 7, 2019 at 4:46 AM Connor Kuehl <connor.kuehl at canonical.com> wrote:
> >>
> >> On 12/1/19 8:51 PM, Po-Hsu Lin wrote:
> >>>  From the commit message:
> >>> In dcn*_create_resource_pool the allocated memory should be released if
> >>> construct pool fails.
> >>>
> >>> This patch can be cherry-picked into B/D/E/F. The generated patch for
> >>> Bionic can be applied to Disco, the one from Eoan can be applied to
> >>> Focal.
> >>
> >> Even though it just looks like offset adjustments, I'd err on turning
> >> the "cherry picked from " line into a "backported from" for the series
> >> (probably Bionic/Disco?) that the mainline patch doesn't directly apply
> >> to with "git am".
> >>
> >> Acked-by: Connor Kuehl <connor.kuehl at canonical.com>
> >>
> >>>
> >>> Kernel test builds OK.
> >>>
> >>> Navid Emamdoost (1):
> >>>    drm/amd/display: prevent memory leak
> >>>
> >>>   drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 1 +
> >>>   drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 +
> >>>   drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 1 +
> >>>   drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 1 +
> >>>   drivers/gpu/drm/amd/display/dc/dcn10/dcn10_resource.c   | 1 +
> >>>   5 files changed, 5 insertions(+)
> >>>
> >>
> >
>



More information about the kernel-team mailing list