Message-ID: <CAPM=9twG7By95nYrkoyLtAT5YPV9WdMUgVPwjuZ9kiZFuse+Fg@mail.gmail.com>
Date: Thu, 31 Jul 2025 13:39:32 +1000
From: Dave Airlie <airlied@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Simona Vetter <simona@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm for 6.17-rc1

On Thu, 31 Jul 2025 at 13:05, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> ,
>
> On Tue, 29 Jul 2025 at 14:06, Dave Airlie <airlied@...il.com> wrote:
> >
> > I've done a pass at merging mostly taking from drm-tip:
> > https://github.com/airlied/linux/tree/drm-next-6.17-rc1-merged
>
> Hmm. My resolution is pretty different, but part of it is that your
> test-merge has a different top-of-tree than the tree you actually sent
> me. I think you added commits
>
>   b213eb34f857 ("drm/tidss: oldi: convert to devm_drm_bridge_alloc() API")
>   66cdf05f8548 ("drm/tidss: encoder: convert to devm_drm_bridge_alloc()")
>
> to the drm tree after you did your test merge.
>
> That said, ignoring those differences, the other ones I'm pretty sure
> your merge is wrong. For example, you left a duplicate
>
>         err = xe_gt_pagefault_init(gt);
>         if (err)
>                 return err;
>
> in xe_gt_init().
>
> Also, you didn't undo the dma_buf addition to 'struct
> virtio_gpu_object', that was added by commit 44b6535d8ace
> ("drm/virtio: Fix NULL pointer deref in virtgpu_dma_buf_free_obj()"),
> but that commit was a fix for the problems that were reverted by
> 0ecfb8ddb953 ("Revert "drm/virtio: Use dma_buf from GEM object
> instance"").
>
> In etnaviv_sched.c, you seem to have missed the "Rename
> DRM_GPU_SCHED_STAT_NOMINAL to DRM_GPU_SCHED_STAT_RESET" in commit
> 0a5dc1b67ef5.
>
> And you have missing MEDIA_VERSION / GRAPHICS_VERSION entries in
> xe_wa_oob.rules from commits c96e0df4e9f5f and b1c37a0030b27.
>
> ANYWAY.

I also need to check if the Intel folks who did drm-tip merges dropped
some things wrong, since I mostly copy from those. The etnaviv one I'd
screwed up definitely, I didn't do an arm build on the merged tree,
and I probably should ensure I do that in the future.

>
> My point isn't so much that I think your merge is wrong - it's very
> possible that I have made other mistakes to make up for yours. But my
> point really is that these drm merges are rather messy and
> error-prone.

Agreed, the error-proneness of them is my main worry, in our internal
tip dev we try and get the knowledgeable people to do the merges, so
my trial merges are definitely not something I practice often, so I'm
happier that you are better at them than me.

>
> But I do think that the drm people are doing actively wrong things
> with the random cherry-picks back and forth: they cause these
> conflicts, and I *really* think you should look at maybe using stable
> fixes branches instead.
>
> Would that require more care and cleaner trees? Yes. And that's kind
> of the point. You are being messy, and it's affecting the quality of
> the end result.

I'm not sure how to parse, stable fixes branch, do you mean stable as
in a special branch for stable tree? or a fixes tree we don't rebase
every rc?

Currently all the base (drm, intel, xe, amdgpu) fixes branches are
stable, we backmerge into them after rc1, and very occasionally
afterwards if a backmerge from rc5/6 is needed.
I pull those stable branches into your latest rc each week and send it to you.

We should only cherry-pick one direction, things that go into -next
and are recognised as fixes are cherry-picked into -fixes. The people
doing the cherry-picking are not always the original developers, and
the patches for fixes are often part of larger refactors.
Because of that, things that end up in -fixes are often refactors and
not clean cherry-picks. Then we get the fun of having a revert in
fixes, and a fix in next and shit starts to get messy, (though in this
case only one or two of the conflicts are revert related problems).

I'm happy with mostly correct, since the downstream devs will
eventually pull this into CI and fix it up anyways, but this time it
was very ugly, and I'll make sure everyone tries to review the merge.

> But that one looks like gcc doing some very strange things with
> coverage tracing, so I am currently inclined to blame it on odd
> compiler output and objtool rather than the drm tree itself.
>
> But I really wish you had a better model for "backport fixes" than the
> mess you have now.
>
> Because it clearly is causing potential problem spots.

It is, I just can't figure out a better plan, myself and Simona have
gone over this multiple times, and the answers we get from others is
just have your developers know in advance that the thing they are
fixing in next should go into fixes first, but then we have to forward
merge fixes into next more often, and large teams of developers have
to be aware of the rc cycle and rules around what is acceptable when.
Scaling sucks here and these are large teams, who are often working
far ahead of the rc cycle.

Dave.

Powered by blists - more mailing lists