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

[Kleber Souza]

Hi Sam,

On 2020-01-02 12:39, Po-Hsu Lin wrote:
> 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

I would try to apply without -C2 first in all the target trees. If it doesn't
work, then try with -C2. If it works, keep the SHA1 as cherry-pick but
make a note on the cover letter that -C2 is needed. If it doesn't work in some
of the trees, then those need to be labeled as backported.

>   3. Reset HEAD^ in our tree, and run git cherry-pick SHA1 to
> determine if it can be called as a cherry-pick

To be called as cherry-pick the patches need to be able to applied with
'git am' from the original SHA1 as stated above. If it doesn't work
the patches need to be labeled as backported even if 'git cherry-pick' applies
it.

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

This script hasn't had any change in years, so I guess people are not
really using it. Looking at the source it seems to not really differentiate
between a clean cherry-pick and a backport.


Thanks,
Klber

> 
> 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(+)
>>>>>
>>>>
>>>
>>