Re: [PATCH v2] rust: devres: optimize type name allocation and fix truncation
From: David Laight
Date: Tue May 26 2026 - 11:28:39 EST
On Tue, 26 May 2026 14:37:44 +0200
Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote:
> On Tue, May 26, 2026 at 1:58 PM Aary Milind Kinge <kingeaary@xxxxxxxxx> wrote:
> >
> > The unconditional 128-byte const array allocation for every unique
> > `Devres<T>` caused unnecessary .rodata bloat in production builds,
>
> Wasn't the string deduplicated?
>
> > terminator), the copy routine now appends "..." at the end — copying
>
> Did an LLM assist this patch? If so, please add a tag:
>
> https://docs.kernel.org/process/generated-content.html
> https://docs.kernel.org/process/coding-assistants.html
>
> Moreover, this should be sent to the right maintainers and reviewers,
> e.g. at least to "DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS". Cc'ing
> them here, but also please Cc all the "RUST" entry.
>
> > + let mut buf = [0u8; 128];
>
> Why is there a hardcoded literal? Please use constants where possible,
> deriving the rest of the literals from that.
>
> > + let mut len = 0;
> > + while len < 128 && static_buf[len] != 0 {
> > + len += 1;
> > + }
> > +
> > + // SAFETY: `static_buf` is promoted to static memory, and we verified the null byte.
>
> This should explain why this is all OK, e.g. why it doesn't go out of
> bounds (a local-only reading of the loop above would appear to make it
> so).
I'm no rust expert (or novice) but that code all looks like run-time
initialisers rather that the static data you really want.
Can you generate the '\0' terminated C 'string' by including an explicit
zero byte in the rust one?
-- David