On Mon, 13 Jan 2025 at 07:09, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 13, 2025 at 06:01:51AM +1000, Dave Airlie wrote:
> > On Mon, 13 Jan 2025 at 05:51, Dave Airlie <airlied@xxxxxxxxx> wrote:
> > >
> > > On Sun, 12 Jan 2025 at 22:19, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
> > > > > Reviewed-by: Matthew Brost <matthew.brost@xxxxxxxxx> # commit 1
> > > > > Reviewed-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
> > > > > Cc: stable@xxxxxxxxxxxxxxx # 6.12+
> > > > > Reviewed-by: Jonathan Cavitt <jonathan.cavitt@xxxxxxxxx>
> > > > > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
> > > > > Link: https://patchwork.freedesktop.org/patch/msgid/20241220171919.571528-2-umesh.nerlige.ramappa@xxxxxxxxx
> > > > > (cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
> > > > > Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
> > > > > (cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)
> > > >
> > > > 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.
> > > >
> > > > 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.
> > >
> > > All subsystems that grow to having large teams (more than 2-4 people)
> > > working on a single driver will eventually hit the scaling problem,
> > > just be glad we find things first so everyone else knows how to deal
> > > with it later.
> > >
> > > >
> > > > 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.
> > >
> > > None of what you are saying makes any sense here. Explain how patches
> > > are backported to stable releases before they end up in Linus's tree
> > > to me like I'm 5, because there should be no possible workflow where
> > > that can happen, stable pulls from patches in Linus' tree, not from my
> > > tree or drm-next or anywhere else. Now it might appear that way
> > > because tooling isn't prepared or people don't know what they are
> > > looking at, but I still don't see the actual problem.
> > >
> > > >
> > > > 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.
> > >
> > > Fix the tools.
> > >
> > > >
> > > > 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.
> > >
> > > How do you recommend we do that, edit the immutable git history to
> > > remove the stable
> > > tag from the original commit?
> > >
> > > >
> > > > I'm tired of it, please, just stop. I am _this_ close to just ignoring
> > > > ALL DRM patches for stable trees...
> > >
> > > If you have to do, go do it. The thing is the workflow is there for a
> > > reason, once you have a large enough team, having every single team
> > > member intimately aware of the rc schedule to decide where they need
> > > to land patches doesn't scale. If you can't land patches to a central
> > > -next tree and then pick those patches out to a -fixes tree after a
> > > maintainer realises they need to be backported to stable. Now I
> > > suppose we could just ban stable tags on the next tree and only put
> > > them on the cherry-picks but then how does it deal with the case where
> > > something needs to be fixes in -next but not really urgent enough for
> > > -fixes immediately. Would that be good enough, no stable tags in -next
> > > trees, like we could make the tooling block it? But it seems like
> > > overkill, to avoid fixing some shitty scripts someone is probably
> > > selling as a security application.
> >
> > If you were to ignore stable tags on drm, could we then write a tool
> > that creates a new for-stable tree that just strips out all the
> > fixes/backports/commits and recreates it based on Linus commits to
> > you, or would future duplicate commits then break tools?
>
> That would be great, just pick which commit id to reference (i.e. the
> one that shows up in Linus's tree first.)
>
> But then, be careful with the "Fixes:" tags as well, those need to line
> up and match the correct ones.
>
> We create a "web" when we backport commits, and mark things for "Fixes:"
> When we get those ids wrong because you all have duplicate commits for
> the same thing, everything breaks.
>
> > I just don't get what the ABI the tools expect is, and why everyone is
> > writing bespoke tools and getting it wrong, then blaming us for not
> > conforming. Fix the tools or write new ones when you realise the
> > situation is more complex than your initial ideas.
>
> All I want to see and care about is:
>
> - for a stable commit, the id that the commit is in Linus's tree.
> - for a Fixes: tag, the id that matches the commit in Linus's tree AND
> the commit that got backported to stable trees.
>
> That's it, that's the whole "ABI". The issue is that you all, for any
> number of commits, have 2 unique ids for any single commit and how are
> we supposed to figure that mess out...
Pretty sure we've explained how a few times now, not sure we can do much more.
If you see a commit with a cherry-pick link in it and don't have any
sight on that commit in Linus's tree, ignore the cherry-pick link in
it, assume it's a future placeholder for that commit id. You could if
you wanted to store that info somewhere, but there shouldn't be a
need.
When the initial commit enters during the next merge window, you look
for that subject or commit id in the stable tree already, if it
exists, dump the latest Linus patch on the floor, it's already in
stable your job is done.
When future tools are analysing things, they will see the patch from
the merge window, the cherry-picked patches in the fixes tree, and
stable will reference the fixes, and the fixes patch will reference
the merge window one?
I'm just not seeing what I'm missing here, fixes tags should work
fine, but I think when we cherry-pick patches from -next that fix
other patches from -next maybe the fixes lines should be reworked to
reference the previous Linus tree timeline not the future one. not
100% sure this happens? Sima might know more.
Now previously I think we'd be requested to remove the cherry-picks
from the -fixes commits as they were referencing things not in Linus'
tree, we said it was a bad idea, I think we did it anyways, we got
shouted at, we put it back, we get shouted that we are referencing
commits that aren't in Linus tree. Either the link is useful
information and we just assume cherry-picks of something we can't see
are a future placeholder and ignore it until it shows up in our
timeline.
I think we could ask to not merge things into -next with stable cc'ed
but I think that will result in a loss of valuable fixes esp for
backporters.
Dave.
