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: <20250829204840.GEaLISKGTwuScnDF8Y@fat_crate.local>
Date: Fri, 29 Aug 2025 22:48:40 +0200
From: Borislav Petkov <bp@...en8.de>
To: Alex Deucher <alexdeucher@...il.com>
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 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.

Thanks for listening. :-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette