Re: [RFC PATCH v2 01/11] objtool/klp: Fix checksums and copying of wide strings

[Longjun Luo]

Sorry, I left out the debugging context here. Both comments refer to
specific kernel build artifacts:

On Thu, Nov 12, 2026 at 06:42:36PM -0800, Josh Poimboeuf wrote:
> Please give example(s) of such "wide strings" in the changelog.
>
> > +/* Wide strings, such as the u16 PSR setup table, end at an all-zero element. */
> > +ssize_t elf_string_len(struct section *sec, unsigned long offset)
>
> What is the "u16 PSR setup table"?

PSR stands for Panel Self Refresh.

Source    : drivers/gpu/drm/display/drm_dp_helper.c: drm_dp_psr_setup_time()
            /* macros expanded */
            static const u16 psr_setup_time_us[] = { 330, 275, 220,
165, 110, 55, 0 };
Section   : .rodata.str2.2 (SHF_STRINGS, sh_entsize = 2, Clang ThinLTO)
Bytes     : 4a 01 13 01 dc 00 a5 00 6e 00 37 00 00 00
                        ^^^^^
                        220 (0x00dc) contains a zero byte at offset +5

objtool   : strlen() returns 5. The checksum hashes only 5 bytes, and
            the copy includes only 6 of the table's 14 bytes.

> > + /*
> > + * FIXME: GCC's range_string() uses a one-past-end string pointer.
> > + * strlen() reads past the section; preserve the string base and addend.
> > + */
> > + if (entsize == 1)
> > + return strlen(sec->data->d_buf + offset);
>
> I don't understand what this comment means either.  Please make sure all
> comments and changelogs are written by humans, as LLMs tend to write
> nonsensically.

Source    : lib/vsprintf.c: range_string()
            p = string_nocheck(p, pend, "[range ", default_str_spec);
Section   : .rodata.range_string.isra.0.str1.1 (8 bytes: "[range \0")
Reloc     : range_string.isra.0+0x9a: R_X86_64_32S .LC22+8

GCC note  : Uses .LC22+8 (one-past-the-end pointer) as a loop bound without
            dereferencing it.
objtool   : Passes offset = 8 to strlen(sec->data->d_buf + 8), reading past
            the 8-byte section. Fixing this requires tracking the base
            string (.LC22) and the +8 addend separately (left as a FIXME).

I came across both while testing on full kernel builds rather than in
production livepatching, so I'll leave it to you whether they are worth
addressing in practice.

Longjun