linux-kernel - Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource seems too big for the bo

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: <CADnq5_MbpYmC2PSyOr0gQk7F8mVz0-LG3dZtUZS2HhV8LTgDww@mail.gmail.com>
Date: Sat, 30 Aug 2025 12:30:09 -0400
From: Alex Deucher <alexdeucher@...il.com>
To: Borislav Petkov <bp@...en8.de>
Cc: amd-gfx@...ts.freedesktop.org, Alex Deucher <alexander.deucher@....com>, 
	Christian König <christian.koenig@....com>, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: evergreen_packet3_check:... radeon 0000:1d:00.0: vbo resource
 seems too big for the bo

On Fri, Aug 29, 2025 at 4:48 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Aug 29, 2025 at 09:40:44PM +0200, Borislav Petkov wrote:
> > On Fri, Aug 29, 2025 at 02:26:50PM -0400, Alex Deucher wrote:
> > > Have you updated mesa?  Looks like a userspace change.
> >
> > Yeah, I did a long overdue OS upgrade today:
> >
> > $ grep -i mesa /var/log/dpkg.log
>
> Btw, this thing:
>
>                                 if (p->rdev && (size + offset) > radeon_bo_size(reloc->robj)) {
>                                         /* force size to size of the buffer */
>                                         dev_warn_ratelimited(p->dev, "vbo resource seems too big for the bo\n");
>                                         ib[idx+1+(i*8)+1] = radeon_bo_size(reloc->robj) - offset;
>                                 }
>
> is yet another example of useless flooding of dmesg.
>
> It's not like I can do anything about it except report it. And that thing
> fires every 5s or so.
>
> You could consider turning that into a _once thing and be done with it.
>
> And someone already ratelimited them:
>
> 59d76d6bc206 ("drm/radeon: ratelimit bo warnings")
>
> but it ain't enough.
>
> $ dmesg | grep "vbo resource" | wc -l
> 22393
>
> So even if I go and find which commit added it:
>
>   cb5fcbd540b4 ("drm/radeon/kms/evergreen: add initial CS parser")
>
> I'm still none the wiser. And I'm not even a normal user - I have seen kernel
> code in the past :-)
>
> Hell, I don't even know what CS is...
>
> /me goes and searches the web a bit...
>
> Aha, it could be a command submission parser or so. Still have no clue what
> this warning is telling me.
>
> Going back to searching the web...
>
> ok, so it looks like this is validating some packet3 set resource thing and
> when the resource type? is a SQ_TEX_VTX_VALID_BUFFER - perhaps a valid vertex
> buffer? Vertex buffer I understand. But texture vertex buffer?
>
> Anyway, it checks whether the vbo (vertex buffer object?) resource is
> too big for the buffer object which has gotten as some sort of a relocation
> packet 3 thing...
>
> And I still have no clue what is going on. Perhaps the new MESA is sending
> wrong command types, who knows.
>
> I absolutely cannot fix it - that's for sure.
>
> And so this rambling of mine confirms my old theory that the warning and error
> messages we put in the kernel are not really useful. Especially to users.
>
> Because there isn't a whole lot they can do about them except reporting them
> to those who can actually do something about.
>
> I.e., those messages might as well be hashes which we can stick into a lookup
> table to fish out a longer string which tells us what is going on.
>
> So I *think* you should make this a once message or *at* *least* ratelimit the
> hell of it so that it appears very seldomly. The rule of thumb should be what
> you want this message to do?
>
> To make a user report it to you?
>
> Or something else?
>
> In any case, I am already very picky with the error messages visible to users
> in the code I'm maintaining, this'll make me be even stricter.
>
> Oh well.

Yes, I agree these should be warn_once().  If you send a patch I'll
apply it, otherwise, I'll take a look next week.  For some background,
older GPUs did not support memory protection, so the kernel driver
validates all of the command submissions (CS) from userspace to make
sure the commands would not access any memory they shouldn't.  In your
case it's a vertex buffer object (VBO) which contains vertex data for
the 3D engine on the GPU.  So newer mesa code is sending a command
submission with an invalid vbo size.  As such the kernel driver
rejects the command submission.  This may result in subtle rendering
issues as the invalid command submission does not get sent to the
hardware.  I would suggest filing a mesa bug report:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/

Alex