[git pull] drm fixes for 6.13-rc1

[Alex Deucher]

On Fri, Nov 29, 2024 at 4:57 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> 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?

Already fixed with this patch:
https://patchwork.freedesktop.org/patch/625940/
Will be in my fixes PR this week.

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