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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2024110521-mummify-unloved-4f5d@gregkh>
Date: Tue, 5 Nov 2024 07:57:36 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Fedor Pchelkin <pchelkin@...ras.ru>
Cc: Sasha Levin <sashal@...nel.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 04, 2024 at 05:55:28PM +0300, Fedor Pchelkin 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
> 
> 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.

No, all of this mess needs to be fixed up on the drm developer's side,
they are the ones doing this type of crazy "let's commit the same patch
to multiple branches and then reference a commit that will show up at an
unknown time in the future and hope for the best!" workflow.

I'm amazed it works at all, they get to keep fixing up this mess as this
is entirely self-inflicted.

greg k-h