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] [day] [month] [year] [list]

Message-ID: <CADnq5_PBLv4EDAPY23B6QztH6bnbht8Nzy9dd+=T4_dH4RwS_g@mail.gmail.com>
Date: Mon, 2 Dec 2024 09:10:50 -0500
From: Alex Deucher <alexdeucher@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Dave Airlie <airlied@...il.com>, Alex Deucher <alexander.deucher@....com>, 
	Sasha Levin <sashal@...nel.org>, 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 Fri, Nov 29, 2024 at 4:57 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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?

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