linux-kernel - Re: [PATCH 0/1] On DRM -> stable process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADnq5_OR9T5Ocxu6pRu38uzdmcV7_um_6aK4vYefhMiZ0gJJSA@mail.gmail.com>
Date: Mon, 4 Nov 2024 10:12:24 -0500
From: Alex Deucher <alexdeucher@...il.com>
To: Fedor Pchelkin <pchelkin@...ras.ru>
Cc: Sasha Levin <sashal@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	stable@...r.kernel.org, Alex Deucher <alexander.deucher@....com>, 
	Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>, 
	Rodrigo Siqueira <Rodrigo.Siqueira@....com>, Christian König <christian.koenig@....com>, 
	"Pan, Xinhui" <Xinhui.Pan@....com>, David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, 
	Fangzhi Zuo <Jerry.Zuo@....com>, Wayne Lin <wayne.lin@....com>, amd-gfx@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	lvc-project@...uxtesting.org, Alexey Khoroshilov <khoroshilov@...ras.ru>, 
	Mario Limonciello <mario.limonciello@....com>, Jonathan Gray <jsg@....id.au>
Subject: Re: [PATCH 0/1] On DRM -> stable process

On Mon, Nov 4, 2024 at 9:55 AM Fedor Pchelkin <pchelkin@...ras.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