Call trace on boot after upgrade to Linux kernel 6.x

[chr0mag]

I've been seeing the call trace below when I boot my APU2C4 after moving to 6.x kernels. I've used a few 6.0.x and 6.1.x kernels and they've all exhibited the same behaviour.

I'm currently running:

% uname -a
Linux apu2c4 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux

Upgrading to the latest mainline firmware shows the same behaviour:

% dmidecode --string bios-version       
v4.17.0.2

I haven't noticed any system instability or other issues as a result.

The call trace:

% journalctl --boot=0 --priority=4 --no-pager

Dec 31 21:00:33 apu2c4 kernel: ------------[ cut here ]------------
Dec 31 21:00:33 apu2c4 kernel: memcpy: detected field-spanning write (size 32) of single field "&device->entry" at drivers/firmware/google/coreboot_table.c:104 (size 8)
Dec 31 21:00:33 apu2c4 kernel: WARNING: CPU: 0 PID: 241 at drivers/firmware/google/coreboot_table.c:104 coreboot_table_probe+0x1ba/0x1e2 [coreboot_table]
Dec 31 21:00:33 apu2c4 kernel: Modules linked in: pcc_cpufreq(-) coreboot_table(+) acpi_cpufreq mac_hid ledtrig_netdev fuse bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 mmc_block sdhci_pci cqhci sdhci mmc_core crc32c_intel xhci_pci xhci_pci_renesas gpio_keys
Dec 31 21:00:33 apu2c4 kernel: CPU: 0 PID: 241 Comm: systemd-udevd Not tainted 6.1.1-arch1-1 #1 9bd09188b430be630e611f984454e4f3c489be77
Dec 31 21:00:33 apu2c4 kernel: Hardware name: PC Engines apu2/apu2, BIOS v4.17.0.2 07/28/2022
Dec 31 21:00:33 apu2c4 kernel: RIP: 0010:coreboot_table_probe+0x1ba/0x1e2 [coreboot_table]
Dec 31 21:00:33 apu2c4 kernel: Code: 08 00 00 00 48 89 c6 48 89 04 24 48 c7 c2 00 a1 57 c0 48 c7 c7 48 a1 57 c0 4c 89 44 24 08 c6 05 f3 1e 00 00 01 e8 b1 a1 a4 e3 <0f> 0b 4c 8b 44 24 08 48 8b 04 24 e9 71 ff ff ff 41 bf ea ff ff ff
Dec 31 21:00:33 apu2c4 kernel: RSP: 0018:ffffafeb40703b48 EFLAGS: 00010286
Dec 31 21:00:33 apu2c4 kernel: RAX: 0000000000000000 RBX: ffff9e76046f2000 RCX: 0000000000000027
Dec 31 21:00:33 apu2c4 kernel: RDX: ffff9e762ac21668 RSI: 0000000000000001 RDI: ffff9e762ac21660
Dec 31 21:00:33 apu2c4 kernel: RBP: ffffafeb400d5018 R08: 0000000000000000 R09: ffffafeb407039d0
Dec 31 21:00:33 apu2c4 kernel: R10: 0000000000000003 R11: ffffffffa52cb768 R12: 0000000000000000
Dec 31 21:00:33 apu2c4 kernel: R13: ffffafeb400d5000 R14: ffff9e7600c0d810 R15: 0000000000000000
Dec 31 21:00:33 apu2c4 kernel: FS:  00007f62a7860080(0000) GS:ffff9e762ac00000(0000) knlGS:0000000000000000
Dec 31 21:00:33 apu2c4 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 31 21:00:33 apu2c4 kernel: CR2: 000055733bf1d2d8 CR3: 000000010259a000 CR4: 00000000000406f0
Dec 31 21:00:33 apu2c4 kernel: Call Trace:
Dec 31 21:00:33 apu2c4 kernel:  <TASK>
Dec 31 21:00:33 apu2c4 kernel:  platform_probe+0x48/0x90
Dec 31 21:00:33 apu2c4 kernel:  really_probe+0xde/0x380
Dec 31 21:00:33 apu2c4 kernel:  ? pm_runtime_barrier+0x54/0x90
Dec 31 21:00:33 apu2c4 kernel:  __driver_probe_device+0x78/0x170
Dec 31 21:00:33 apu2c4 kernel:  driver_probe_device+0x1f/0x90
Dec 31 21:00:33 apu2c4 kernel:  __driver_attach+0xd5/0x1d0
Dec 31 21:00:33 apu2c4 kernel:  ? __device_attach_driver+0x110/0x110
Dec 31 21:00:33 apu2c4 kernel:  bus_for_each_dev+0x8b/0xd0
Dec 31 21:00:33 apu2c4 kernel:  bus_add_driver+0x1b2/0x200
Dec 31 21:00:33 apu2c4 kernel:  driver_register+0x8d/0xe0
Dec 31 21:00:33 apu2c4 kernel:  coreboot_table_driver_init+0x2f/0x1000 [coreboot_table 88ba60255f1ecf81d7bd02d65b11614bb24acd8e]
Dec 31 21:00:33 apu2c4 kernel:  ? 0xffffffffc057e000
Dec 31 21:00:33 apu2c4 kernel:  do_one_initcall+0x5d/0x220
Dec 31 21:00:33 apu2c4 kernel:  do_init_module+0x4a/0x1e0
Dec 31 21:00:33 apu2c4 kernel:  __do_sys_init_module+0x17f/0x1b0
Dec 31 21:00:33 apu2c4 kernel:  do_syscall_64+0x5f/0x90
Dec 31 21:00:33 apu2c4 kernel:  ? handle_mm_fault+0xdf/0x2d0
Dec 31 21:00:33 apu2c4 kernel:  ? do_user_addr_fault+0x1e0/0x6a0
Dec 31 21:00:33 apu2c4 kernel:  ? do_syscall_64+0x6b/0x90
Dec 31 21:00:33 apu2c4 kernel:  ? exc_page_fault+0x74/0x170
Dec 31 21:00:33 apu2c4 kernel:  entry_SYSCALL_64_after_hwframe+0x63/0xcd
Dec 31 21:00:33 apu2c4 kernel: RIP: 0033:0x7f62a8321eae
Dec 31 21:00:33 apu2c4 kernel: Code: 48 8b 0d dd ee 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d aa ee 0c 00 f7 d8 64 89 01 48
Dec 31 21:00:33 apu2c4 kernel: RSP: 002b:00007ffe9b2cc548 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
Dec 31 21:00:33 apu2c4 kernel: RAX: ffffffffffffffda RBX: 000055733bf17990 RCX: 00007f62a8321eae
Dec 31 21:00:33 apu2c4 kernel: RDX: 00007f62a8824343 RSI: 0000000000003eb7 RDI: 00007f62a693e010
Dec 31 21:00:33 apu2c4 kernel: RBP: 00007f62a8824343 R08: 27d4eb2f165667c5 R09: 85ebca77c2b2ae63
Dec 31 21:00:33 apu2c4 kernel: R10: 00007f62a8315aeb R11: 0000000000000246 R12: 0000000000020000
Dec 31 21:00:33 apu2c4 kernel: R13: 000055733bf16020 R14: 000055733bf17990 R15: 000055733bf15290
Dec 31 21:00:33 apu2c4 kernel:  </TASK>
Dec 31 21:00:33 apu2c4 kernel: ---[ end trace 0000000000000000 ]---

[mlramd]

From the coreboot mailing list:
https://mail.coreboot.org/hyperkitty/list/[email protected]/thread/FGODC5MC5FEQ6FXAQFPIGQFWVDRGPCT2/

On Thu, Dec 29, 2022 at 6:43 AM Julius Werner wrote:

I can confirm that this warning is a false positive, at least. We're
intentionally copying bytes from beyond the end of the header
structure in this case.

I don't know what kind of kernel system detects this stuff at runtime
and how to silence it. Probably need to add a void pointer cast or
something?

[metux]

What happens on 5.x kernels ?

If it's a kernel regression, this should be reported on lkml, so we can take care of it.
We kernel maintains usually don't monitor ticket systems of individual hw vendors.

[chr0mag]

I haven't noticed this since kernel 6.1.8. Kernels 6.1.9/6.1.11/6.1.12 all booted without this call trace on my APU2C4. The mailing list thread @mlramd linked to above has a proposed patch, so perhaps this made its way into the stable kernel.