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

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Fri, Nov 13, 2026 at 12:32:20PM +0800, Longjun Luo wrote:
> 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.

It's probably worth fixing, just the comments and commit log need to be
clear about what exactly we're fixing.

-- 
Josh