linux-kernel - Re: [git pull] drm fixes for 6.13-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh74-reWGqpP+i3O8usrS1Jr12UGGMCfaK58_0aK5Lw_Q@mail.gmail.com>
Date: Fri, 29 Nov 2024 13:31:37 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dave Airlie <airlied@...il.com>, Alex Deucher <alexander.deucher@....com>, 
	Sasha Levin <sashal@...nel.org>
Cc: Sima Vetter <sima@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm fixes for 6.13-rc1

On Thu, 28 Nov 2024 at 12:42, Dave Airlie <airlied@...il.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