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

[Jani Nikula <jani.nikula@linux.intel.com>]

On Tue, 14 Jan 2025, Dave Airlie <airlied@gmail.com> wrote:
> On Sun, 12 Jan 2025 at 22:19, Greg KH <gregkh@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@intel.com>
>> > Reviewed-by: Matthew Brost <matthew.brost@intel.com> # commit 1
>> > Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
>> > Cc: stable@vger.kernel.org # 6.12+
>> > Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
>> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@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@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.

The automatic cherry-pick for 6.12 stable failed, and Umesh provided the
manually cherry-picked patch for it, apparently using -x in the process,
adding the second cherry-pick annotation. The duplicate annotation
hasn't been merged to any tree, it's not part of the process, it's just
what happened with this manual stable backport. I think it would be wise
to ignore that part of the whole discussion. It's really not that
relevant.

BR,
Jani.


>
> 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

-- 
Jani Nikula, Intel