[PATCH 0/1] On DRM -> stable process

[Alex Deucher]

On Mon, Nov 4, 2024 at 9:55 AM Fedor Pchelkin <pchelkin at ispras.ru> wrote:
>
> On Tue, 29. Oct 18:12, Fedor Pchelkin wrote:
> > On Tue, 29. Oct 10:20, Sasha Levin wrote:
> > > On Tue, Oct 29, 2024 at 04:31:40PM +0300, Fedor Pchelkin wrote:
> > > > BTW, a question to the stable-team: what Git magic (3-way-merge?) let the
> > > > duplicate patch be applied successfully? The patch context in stable trees
> > > > was different to that moment so should the duplicate have been expected to
> > > > fail to be applied?
> > >
> > > Just plain git... Try it yourself :)
> > >
> > > $ git checkout 282f0a482ee6
> > > HEAD is now at 282f0a482ee61 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> > >
> > > $ git cherry-pick 7c887efda1
> >
> > 7c887efda1 is the commit backported to linux-6.1.y. Of course it will apply
> > there.
> >
> > What I mean is that the upstream commit for 7c887efda1 is 8151a6c13111b465dbabe07c19f572f7cbd16fef.
> >
> > And cherry-picking 8151a6c13111b465dbabe07c19f572f7cbd16fef to linux-6.1.y
> > on top of 282f0a482ee6 will not result in duplicating the change, at least
> > with my git configuration.
> >
> > I just don't understand how a duplicating if-statement could be produced in
> > result of those cherry-pick'ings and how the content of 7c887efda1 was
> > generated.
> >
> > $ git checkout 282f0a482ee6
> > HEAD is now at 282f0a482ee6 drm/amd/display: Skip Recompute DSC Params if no Stream on Link
> >
> > $ git cherry-pick 8151a6c13111b465dbabe07c19f572f7cbd16fef
> > Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> > HEAD detached at 282f0a482ee6
> > You are currently cherry-picking commit 8151a6c13111.
> >   (all conflicts fixed: run "git cherry-pick --continue")
> >   (use "git cherry-pick --skip" to skip this patch)
> >   (use "git cherry-pick --abort" to cancel the cherry-pick operation)
> > The previous cherry-pick is now empty, possibly due to conflict resolution.
> > If you wish to commit it anyway, use:
> >
> >     git commit --allow-empty
> >
> > Otherwise, please use 'git cherry-pick --skip'
>
> Sasha,
>
> my concern is that maybe there is some issue with the scripts used for the
> preparation of backport patches.
>
> There are two different upstream commits performing the exact same change:
> - 50e376f1fe3bf571d0645ddf48ad37eb58323919
> - 8151a6c13111b465dbabe07c19f572f7cbd16fef

There were cases where I needed to cherry-pick fixes from -next to
-fixes.  In the past I had not used -x when cherry-picking because I
got warnings about references to commits that were not yet in
mainline.  I have since started using -x when cherry-picking things
from -next to -fixes.

Alex

>
> 50e376f1fe3bf571d0645ddf48ad37eb58323919 was backported to stable kernels
> at first. After that, attempts to backport 8151a6c13111b465dbabe07c19f572f7cbd16fef
> to those stables should be expected to fail, no? Git would have complained
> about this - the patch was already applied.
>
> It is just strange that the (exact same) change made by the commits is
> duplicated by backporting tools. As it is not the first case where DRM
> patches are involved per Greg's statement [1], I wonder if something can be
> done on stable-team's side to avoid such odd behavior in future.
>
> [1]: https://lore.kernel.org/stable/20241007035711.46624-1-jsg@jsg.id.au/T/#u
>
> --
> Thanks,
> Fedor