On 05/12/2025 19:28, David Laight wrote:
On Fri, 5 Dec 2025 11:48:08 +0100
Ard Biesheuvel <[email protected]> wrote:
On Sun, 9 Nov 2025 at 19:00, Ard Biesheuvel <[email protected]> wrote:
...
But I guess much prettier fix would be to simply grow the buffer.
OK, so something like
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -72,7 +72,7 @@ struct intel_memory_region {
u16 instance;
enum intel_region_id id;
char name[16];
- char uabi_name[16];
+ char uabi_name[20];
The observant will notice the 7 bytes of padding following 'private',
and another 7 a little later on.
(I' pretty sure 'bool' is u8).
Oh well, them holes love to be added over time.
Anyway, I have pushed this patch to drm-intel-gt-next so it will appear
in 6.20. Only now I realised I could have suggested to add some Fixes:
tag to it, so it would get automatically picked for 6.19.
My colleagues who are handling drm-intel-next-fixes for 6.19 could
perhaps manually pick it up.
Tvrtko
So extending the buffer doesn't even grow the structure.
The string is only used when printing some stats.
I got lost in a list of #defines and function pointers trying to find
the actual function that did the 'printf'.
David
bool private; /* not for userspace */
struct {
Also, hm, how come gcc does not find the mem->name vsnprintf from
intel_memory_region_set_name?
AFAICT, intel_memory_region_set_name() is never called with a format
string that could produce more than 15/16 bytes of output.
