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