AAARRRGGGHHH!!!! (was Re: [PATCH 6.12.y] xe/oa: Fix query mode of operation for OAR/OAC)

[Dave Airlie]

On Sun, 12 Jan 2025 at 22:19, Greg KH <gregkh at linuxfoundation.org> wrote:
>
> On Fri, Jan 10, 2025 at 12:53:41PM -0800, Umesh Nerlige Ramappa wrote:
> > commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16 upstream
>
> <snip>
>
> > Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close")
> > Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa at intel.com>
> > Reviewed-by: Matthew Brost <matthew.brost at intel.com> # commit 1
> > Reviewed-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
> > Cc: stable at vger.kernel.org # 6.12+
> > Reviewed-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit at intel.com>
> > Link: https://patchwork.freedesktop.org/patch/msgid/20241220171919.571528-2-umesh.nerlige.ramappa@intel.com
> > (cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
> > Signed-off-by: Thomas Hellström <thomas.hellstrom at linux.intel.com>
>
> Oh I see what you all did here.
>
> I give up.  You all need to stop it with the duplicated git commit ids
> all over the place.  It's a major pain and hassle all the time and is
> something that NO OTHER subsystem does.

Let me try and work out what you think is the problem with this
particular commit as I read your email and I don't get it.

This commit is in drm-next as  55039832f98c7e05f1cf9e0d8c12b2490abd0f16
and says Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset
OAC_CONTEXT_ENABLE on OA stream close)

It was pulled into drm-fixes a second time as a cherry-pick from next
as f0ed39830e6064d62f9c5393505677a26569bb56
(cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)

Now the commit it Fixes: 8135f1c09dd2 is also at
0c8650b09a365f4a31fca1d1d1e9d99c56071128

Now the above thing you wrote is your cherry-picked commit for stable?
since I don't see
(cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)
in my tree anywhere.

So this patch comes into stable previously as
f0ed39830e6064d62f9c5393505677a26569bb56 ? and then when it comes in
as 55039832f98c7e05f1cf9e0d8c12b2490abd0f16 you didn't notice you
already had it, (there is where I think the extra step of searching in
git history for the patch (this seems easily automatable) should come
in.

Or is the concern with the Fixes: line referencing the wrong thing?

Dave.
>
> Yes, I know that DRM is special and unique and running at a zillion
> times faster with more maintainers than any other subsystem and really,
> it's bigger than the rest of the kernel combined, but hey, we ALL are a
> common project here.  If each different subsystem decided to have their
> own crazy workflows like this, we'd be in a world of hurt.  Right now
> it's just you all that is causing this world of hurt, no one else, so
> I'll complain to you.
>
> We have commits that end up looking like they go back in time that are
> backported to stable releases BEFORE they end up in Linus's tree and
> future releases.  This causes major havoc and I get complaints from
> external people when they see this as obviously, it makes no sense at
> all.
>
> And it easily breaks tools that tries to track where backports went and
> if they are needed elsewhere, which ends up missing things because of
> this crazy workflow.  So in the end, it's really only hurting YOUR
> subsystem because of this.
>
> And yes, there is a simple way to fix this, DO NOT TAG COMMITS THAT ARE
> DUPLICATES AS FOR STABLE.  Don't know why you all don't do that, would
> save a world of hurt.
>
> I'm tired of it, please, just stop.  I am _this_ close to just ignoring
> ALL DRM patches for stable trees...
>
> greg k-h