All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: David Rheinsberg <david@readahead.eu>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86/insn_decoder_test: allow longer symbol-names
Date: Fri, 29 Nov 2024 15:40:31 +0000	[thread overview]
Message-ID: <20241129154031.GA7195@redhat.com> (raw)

[Sorry for possible mail threading errors, I don't have the original
email in my archive.]

We're hitting the bug mentioned in this old patch:

[https://lore.kernel.org/lkml/Y9ES4UKl%2F+DtvAVS@gmail.com/T/]

> Increase the allowed line-length of the insn-decoder-test to 4k to allow
> for symbol-names longer than 256 characters.
> 
> The insn-decoder-test takes objdump output as input, which may contain
> symbol-names as instruction arguments. With rust-code entering the
> kernel, those symbol-names will include mangled-symbols which might
> exceed the current line-length-limit of the tool.
> 
> By bumping the line-length-limit of the tool to 4k, we get a reasonable
> buffer for all objdump outputs I have seen so far. Unfortunately, ELF
> symbol-names are not restricted in length, so technically this might
> still end up failing if we encounter longer names in the future.
> 
> My compile-failure looks like this:
> 
>     arch/x86/tools/insn_decoder_test: error: malformed line 1152000:
>     tBb_+0xf2>
> 
> ..which overflowed by 10 characters reading this line:
> 
>     ffffffff81458193:   74 3d                   je     ffffffff814581d2 <_RNvXse_NtNtNtCshGpAVYOtgW1_4core4iter8adapters7flattenINtB5_13FlattenCompatINtNtB7_3map3MapNtNtNtBb_3str4iter5CharsNtB1v_17CharEscapeDefaultENtNtBb_4char13EscapeDefaultENtNtBb_3fmt5Debug3fmtBb_+0xf2>

in Fedora:

  https://bugzilla.redhat.com/show_bug.cgi?id=2329496

I notice that BUFSIZE is still set to 256.  Setting it to 512 fixed
the problem for me, although I understand that this is just a hack.

Was there any further effort to get this patch upstream?

Unfortunately I don't know what exact symbol is overflowing in the
Fedora case, but we do have a very full-featured kernel, including
Rust enabled (if that is relevant).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v


             reply	other threads:[~2024-11-29 15:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-29 15:40 Richard W.M. Jones [this message]
2024-12-24 15:24 ` [PATCH] x86/insn_decoder_test: allow longer symbol-names Andrew Halaney
  -- strict thread matches above, loose matches on Subject: below --
2023-01-24 11:04 David Rheinsberg
2023-01-25 11:30 ` Ingo Molnar
2023-01-27 10:27   ` David Rheinsberg
2024-02-20 17:07     ` Miguel Ojeda
2024-04-08 12:51       ` Danilo Krummrich
2024-04-08 15:22         ` Sergio González Collado
2024-04-08 15:30           ` Sergio González Collado

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=20241129154031.GA7195@redhat.com \
    --to=rjones@redhat.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@readahead.eu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.