public inbox for live-patching@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Lawrence <joe.lawrence@redhat.com>
To: live-patching@vger.kernel.org
Cc: Josh Poimboeuf <jpoimboe@kernel.org>, Song Liu <song@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH v3 01/13] objtool/klp: honor SHF_MERGE entry alignment in elf_add_data()
Date: Tue, 17 Feb 2026 11:14:17 -0500	[thread overview]
Message-ID: <aZST2WmYD-B_o0oc@redhat.com> (raw)
In-Reply-To: <20260217160645.3434685-2-joe.lawrence@redhat.com>

On Tue, Feb 17, 2026 at 11:06:32AM -0500, Joe Lawrence wrote:
> When adding data to an SHF_MERGE section, set the Elf_Data d_align to
> the section's sh_addralign so libelf aligns entries within the section.
> This ensures that entry offsets are consistent with previously calculated
> relocation addends.
> 
> Fixes: 431dbabf2d9d ("objtool: Add elf_create_data()")
> Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> ---
>  tools/objtool/elf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 2c02c7b49265..bd6502e7bdc0 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -1375,7 +1375,7 @@ void *elf_add_data(struct elf *elf, struct section *sec, const void *data, size_
>  		memcpy(sec->data->d_buf, data, size);
>  
>  	sec->data->d_size = size;
> -	sec->data->d_align = 1;
> +	sec->data->d_align = (sec->sh.sh_flags & SHF_MERGE) ? sec->sh.sh_addralign : 1;
>  
>  	offset = ALIGN(sec->sh.sh_size, sec->sh.sh_addralign);
>  	sec->sh.sh_size = offset + size;
> -- 
> 2.53.0
> 
> 

This one stretches my ELF internals knowledge a bit, is ^^ true or
should we rely on the section ".str1.8" suffix to indicate internal
alignment?

Here is the repro:

A simple patch to pr_info a few strings to the kernel buffer:

  diff --git a/fs/proc/cmdline.c b/fs/proc/cmdline.c
  index a6f76121955f..5b7f43105ea8 100644
  --- a/fs/proc/cmdline.c
  +++ b/fs/proc/cmdline.c
  @@ -7,6 +7,10 @@

   static int cmdline_proc_show(struct seq_file *m, void *v)
   {
  +	pr_info("ABCDEFGHIJKLMN:   message 1 here\n");
  +	pr_info("OPQRSTUVWXYZ12:   message 2 here\n");
  +	pr_info("34567890abcdef:   message 3 here\n");
  +	pr_info("ghijklmnopqrst:   message 4 here\n");
   	seq_puts(m, saved_command_line);
   	seq_putc(m, '\n');
   	return 0;

results in strange dmesg output:

  [ 6179.571413] ABCDEFGHIJKLMN:   message 1 here
  [ 6179.575689] QRSTUVWXYZ12:   message 2 here
  [ 6179.579788] 90abcdef:   message 3 here
  [ 6179.583541] qrst:   message 4 here

patched/vmlinux.o
-----------------

First thing to note, section .rodata.cmdline_proc_show.str1.8 has
entries with an alignment of 8 bytes and the section is SHF_MERGE:

  $ readelf --wide -S klp-tmp/patched/vmlinux.o
  Section Headers:
  [Nr]      Name                              Type      Address           Off      Size    ES  Flg  Lk  Inf  Al
  [132261]  .rodata.cmdline_proc_show.str1.8  PROGBITS  0000000000000000  23b3000  00009c  01  AMS  0   0    8

  $ eu-objdump -r -j .rela.text.unlikely.cmdline_proc_show klp-tmp/patched/vmlinux.o | grep str1.8
  0000000000000020 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8
  000000000000002c R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x28
  0000000000000038 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x50
  0000000000000044 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x78

  $ eu-objdump -s -j .rodata.cmdline_proc_show.str1.8 klp-tmp/patched/vmlinux.o
  klp-tmp/patched/vmlinux.o: elf64-elf_x86_64

  Contents of section .rodata.cmdline_proc_show.str1.8:
   0000 01364142 43444546 4748494a 4b4c4d4e  .6ABCDEFGHIJKLMN
        ^ (+0x00)                            ^
   0010 3a202020 6d657373 61676520 31206865  :   message 1 he
   0020 72650a00 00000000 01364f50 51525354  re.......6OPQRST
                          ^ (+0x28)                  ^
   0030 55565758 595a3132 3a202020 6d657373  UVWXYZ12:   mess
   0040 61676520 32206865 72650a00 00000000  age 2 here......
   0050 01363334 35363738 39306162 63646566  .634567890abcdef
        ^ (+0x50)                            ^
   0060 3a202020 6d657373 61676520 33206865  :   message 3 he
   0070 72650a00 00000000 01366768 696a6b6c  re.......6ghijkl
                          ^ (+0x78)                  ^
   0080 6d6e6f70 71727374 3a202020 6d657373  mnopqrst:   mess
   0090 61676520 34206865 72650a00           age 4 here..


diff/vmlinux.o
--------------

Same 8-byte alignment of .rodata.cmdline_proc_show.str1.8:

  $ readelf --wide -S klp-tmp/diff/vmlinux.o | grep str1.8
  Section  Headers:
  [Nr]  Name                              Type      Address           Off     Size    ES  Flg  Lk  Inf  Al
  [6]   .rodata.cmdline_proc_show.str1.8  PROGBITS  0000000000000000  000540  000090  01  AMS  0   0    8

  $ eu-objdump -r klp-tmp/diff/vmlinux.o | grep str1.8
  0000000000000020 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8
  000000000000002c R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x28
  0000000000000038 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x50
  0000000000000044 R_X86_64_32S         .rodata.cmdline_proc_show.str1.8+0x78

but notice they do not point to the strings in a now packed section
contents:

  $ eu-objdump -s -j .rodata.cmdline_proc_show.str1.8 klp-tmp/diff/vmlinux.o
  klp-tmp/diff/vmlinux.o: elf64-elf_x86_64

  Contents of section .rodata.cmdline_proc_show.str1.8:
   0000 01364142 43444546 4748494a 4b4c4d4e  .6ABCDEFGHIJKLMN
        ^ (+0x00)                            ^
   0010 3a202020 6d657373 61676520 31206865  :   message 1 he
   0020 72650a00 01364f50 51525354 55565758  re...6OPQRSTUVWX
                          ^ (+0x28)                  ^
   0030 595a3132 3a202020 6d657373 61676520  YZ12:   message
   0040 32206865 72650a00 01363334 35363738  2 here...6345678
   0050 39306162 63646566 3a202020 6d657373  90abcdef:   mess
        ^ (+0x50)                            ^
   0060 61676520 33206865 72650a00 01366768  age 3 here...6gh
   0070 696a6b6c 6d6e6f70 71727374 3a202020  ijklmnopqrst:
                          ^ (+0x78)                  ^
   0080 6d657373 61676520 34206865 72650a00  message 4 here..

--
Joe


  reply	other threads:[~2026-02-17 16:14 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-17 16:06 [PATCH v3 00/13] livepatch-klp-build: small fixups and enhancements Joe Lawrence
2026-02-17 16:06 ` [PATCH v3 01/13] objtool/klp: honor SHF_MERGE entry alignment in elf_add_data() Joe Lawrence
2026-02-17 16:14   ` Joe Lawrence [this message]
2026-03-05  2:33     ` Josh Poimboeuf
2026-03-10 14:02       ` Joe Lawrence
2026-03-10 16:34         ` Josh Poimboeuf
2026-02-17 16:06 ` [PATCH v3 02/13] objtool/klp: fix mkstemp() failure with long paths Joe Lawrence
2026-02-17 17:45   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 03/13] livepatch/klp-build: support patches that add/remove files Joe Lawrence
2026-02-17 17:52   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 04/13] livepatch/klp-build: switch to GNU patch and recountdiff Joe Lawrence
2026-02-17 16:06 ` [PATCH v3 05/13] livepatch/klp-build: add grep-override function Joe Lawrence
2026-02-17 18:22   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 06/13] livepatch/klp-build: add Makefile with check target Joe Lawrence
2026-02-17 18:26   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 07/13] livepatch/klp-build: fix shellcheck complaints Joe Lawrence
2026-02-17 18:30   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 08/13] livepatch/klp-build: improve short-circuit validation Joe Lawrence
2026-02-17 18:29   ` Song Liu
2026-02-17 16:06 ` [PATCH v3 09/13] livepatch/klp-build: fix version mismatch when short-circuiting Joe Lawrence
2026-02-17 16:17   ` Joe Lawrence
2026-02-17 19:25     ` Song Liu
2026-02-18 15:04       ` Joe Lawrence
2026-02-19  2:52         ` Song Liu
2026-02-23 21:13     ` Josh Poimboeuf
2026-03-03  2:20       ` Joe Lawrence
2026-03-05 22:35         ` Josh Poimboeuf
2026-03-05 22:52           ` [PATCH] klp-build: Fix inconsistent kernel version Josh Poimboeuf
2026-03-10 13:45             ` Joe Lawrence
2026-03-10 16:30               ` Josh Poimboeuf
2026-02-17 16:06 ` [PATCH v3 10/13] livepatch/klp-build: provide friendlier error messages Joe Lawrence
2026-02-17 18:32   ` Song Liu
2026-02-23 21:15   ` Josh Poimboeuf
2026-03-03  2:20     ` Joe Lawrence
2026-02-17 16:06 ` [PATCH v3 11/13] livepatch/klp-build: add terminal color output Joe Lawrence
2026-02-17 16:20   ` Joe Lawrence
2026-02-17 18:45   ` Song Liu
2026-02-23 21:28   ` Josh Poimboeuf
2026-02-23 21:32     ` Josh Poimboeuf
2026-03-03  2:24       ` Joe Lawrence
2026-03-05 20:08         ` Josh Poimboeuf
2026-02-17 16:06 ` [PATCH v3 12/13] livepatch/klp-build: report patch validation drift Joe Lawrence
2026-02-17 19:42   ` Song Liu
2026-02-18 15:09     ` Joe Lawrence
2026-02-23 21:40   ` Josh Poimboeuf
2026-03-03  2:27     ` Joe Lawrence
2026-02-17 16:06 ` [PATCH v3 13/13] livepatch/klp-build: don't look for changed objects in tools/ Joe Lawrence
2026-02-17 19:29   ` Song Liu
2026-02-18 15:18     ` Joe Lawrence
2026-02-19  2:55       ` Song Liu
2026-02-23 21:41   ` Josh Poimboeuf
2026-03-03  2:30     ` Joe Lawrence
2026-03-05 20:10       ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZST2WmYD-B_o0oc@redhat.com \
    --to=joe.lawrence@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    --cc=song@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox