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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Jan 14, 2025 at 11:22:26AM +0200, Jani Nikula wrote:
> 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.

On the contrary, this commit shows the whole problem very well.  It is
trivial for people to get confused, the author submitted a backport of a
commit that is NOT in Linus's tree because they got an email telling of
a failure and didn't use the correct id because they looked in the
drm-next branch, NOT in Linus's branch.

Which is why I flagged it, as the commit id used here was not a valid
one at this point in time.  Yes, after -rc1 it would be valid, but
again, totally confusing.

You all are seeing confusion with this development model.  That's the
issue.  Whether or not it's intentional, that's the result.  And because
of it, I am telling you all, the kernel is less secure as it allows us
all to get confused and mis backports and drop fixes incorrectly.

So either you all change the process, or just live with it and the
consequences of having total confusion at times and grumpy stable
developers because of it, and less secure users due to missed bug and
security fixes.

greg k-h