[git pull] drm fixes for 6.13-rc1

[Linus Torvalds]

On Thu, 28 Nov 2024 at 12:42, Dave Airlie <airlied at gmail.com> wrote:
>
> Merge window fixes, mostly amdgpu and xe, with a few other minor ones,
> all looks fairly normal,

Hmm. I've pulled this, but do note the report by Sasha.

The

        if (WARN_ON(!work->func))
                return false;

from __flush_work() looks odd, and is fairly obviously triggered by
this one liner in commit 93df74873703 ("drm/amdgpu/jpeg: cancel the
jpeg worker")

-       bool set_clocks = !cancel_delayed_work_sync(&adev->vcn.idle_work);
+       bool set_clocks = !cancel_delayed_work_sync(&adev->jpeg.idle_work);

where apparently the jpeg.idle_work isn't initialized at that point.

It looks like the initialization is done by amdgpu_jpeg_sw_init(), and
it looks like that cancel_delayed_work_sync() is just done too early.
But I don't know the code. Alex?

The other report by Sasha seems to be a 32-bit issue, where something
calls roundup_pow_of_two() on a thing that would round up past the
32-bit limit. Presumably it works on 64-bit.

But I'm not seeing anything that looks like a likely *cause* of the new warning.

There's a couple possible cases, although this one looks suspicious:

        adev->vm_manager.max_pfn = (uint64_t)vm_size << 18;

        tmp = roundup_pow_of_two(adev->vm_manager.max_pfn);

because it explicitly uses 64-bit types for that max_pfn thing, but
then does that roundup_pow_of_two() that only works on "unsigned
long".

Sasha - it would help if your warning stack dumps had line numbers
(using decode_stacktrace.sh, which you should be familiar with, since
you wrote it...)

I realize that requires some debug info, which might slow down builds
etc, but it would be really nice.

          Linus