Bug 2329496 - kernel FTBFS: arch/x86/tools/insn_decoder_test: error: malformed line 3566260: 2_>:ffffffff81bdd110
Summary: kernel FTBFS: arch/x86/tools/insn_decoder_test: error: malformed line 3566260...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-11-29 15:26 UTC by Richard W.M. Jones
Modified: 2025-03-31 19:58 UTC (History)
18 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2024-11-29 15:26:25 UTC
The kernel in Rawhide fails to build from source.

It eventually fails at:

arch/x86/tools/insn_decoder_test: error: malformed line 3566260:
2_>:ffffffff81bdd110

This is basically the same as the following upstream bug reported
(but not fixed) here:

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

I fixed it by changing the definition of the BUFSIZE macro in
arch/x86/tools/insn_decoder_test.c from 256 -> 512.

2. What is the Version-Release number of the kernel:

kernel-6.13.0-0.rc0.20241128gitb86545e02e8c.11.fc42

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

It seems like it only broke recently.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes, build from source.


Reproducible: Always

Comment 1 Richard W.M. Jones 2024-11-29 15:43:08 UTC
I posted on LKML to ask what happened to that patch:

https://lore.kernel.org/lkml/20241129154031.GA7195@redhat.com/

Comment 2 Adam Williamson 2024-12-02 22:32:15 UTC
jforbes wondered why this doesn't affect the ELN kernel if that's the problem. I have a theory: I think the ELN kernel builds with the RHEL kernel config, which is very different from and much more stripped down than Fedora's. Notably, given the note in the upstream report that "With rust-code entering the kernel, those symbol-names will include mangled-symbols which might exceed the current line-length-limit of the tool", the Fedora config has CONFIG_RUST=y but the RHEL config has it unset. I downloaded https://kojipkgs.fedoraproject.org//packages/kernel/6.13.0/0.rc1.20241202gite70140ba0d2b.14.eln144/x86_64/kernel-core-6.13.0-0.rc1.20241202gite70140ba0d2b.14.eln144.x86_64.rpm and checked the config file it contains, and indeed CONFIG_RUST is not in it, so I think that supports my theory.

Comment 3 Richard W.M. Jones 2025-03-25 11:05:46 UTC
Thanks Dan, who pointed out that we have a (downstream only?) patch in
the Fedora Rawhide kernel that fixes this:

In 'patch-6.14-redhat.patch':

...
diff --git a/arch/x86/tools/insn_decoder_test.c b/arch/x86/tools/insn_decoder_te
st.c
index 472540aeabc2..366e07546344 100644
--- a/arch/x86/tools/insn_decoder_test.c
+++ b/arch/x86/tools/insn_decoder_test.c
@@ -106,7 +106,7 @@ static void parse_args(int argc, char **argv)
        }
 }
 
-#define BUFSIZE 256
+#define BUFSIZE 4096
...

Comment 4 Justin M. Forbes 2025-03-27 13:55:34 UTC
Yes, we are carrying the patch, but upstream keeps ignoring it for some reason. The issue is only in rust which is why it doesn't impact ELN. Over the past couple of releases, multiple people have sent patches upstream which are all variations on this, but none seem to gain traction.


Note You need to log in before you can comment on or make changes to this bug.