[PATCH 0/9] drm: Revert general use of struct drm_gem_object.dma_buf

[Simona Vetter]

On Fri, Jul 11, 2025 at 11:37:30AM -0700, Linus Torvalds wrote:
> On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
> >
> > I'm hoping the login time timeout / hang ends up being due to a known
> > netlink regression, and it just happened to look like a drm issue
> > because it exposes itself as a hang at the first graphical login
> >
> > A netlink regression *might* fit the pattern, in that it might just
> > cause first login dependency issues and resulting timeouts.
> 
> Well, considering the random timing behavior of this bug, it's hard to
> be really sure, but two boots with the alleged "fix" for the netlink
> issue made the behavior worse, so it does look like my problems on
> this machine were a combination of the drm refcounting issue and the
> netlink thing.
> 
> I guess I'll have to do a lot more rebooting to be sure, since the
> hangs and timeouts have been so random. But the netlink "fixes" did
> give me a hang that was very different from the previous ones I've
> seen, so I think the drm code is off the hook on this one.

Ok sounds good, I won't include the drm reverts then. I do think the
change from ->import_attach.dmabuf to ->dma_buf is still suspect, and the
handle_count reference change for fb won't cover all the other places this
might blow up (just less likely since the most common multi-gpu use-cases
are sharing render buffers to a display driver). But better we take
another week to really think this through before rushing things.

The handle_count changes do look reasonable to me too, but for an entirely
different bug around bo import/export. And I think we'll want a testcase
for that to make sure, and evaluate options properly.

But now I'll just type the pr summary and then w/e for me.

Cheers, Sima
-- 
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch