On 2016/2/1 16:32, Jean Delvare wrote: > Le Saturday 30 January 2016 à 15:22 +0800, Xie XiuQi a écrit : >> http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0d.pdf >> >> 0Ch DWORD "Structure table maximum size" >> >> Maximum size of SMBIOS Structure Table, pointed to by >> the Structure Table Address, in bytes. The actual size is >> guaranteed to be less or equal to the maximum size >> >> Signed-off-by: Xie XiuQi <[email protected]> >> --- >> dmidecode.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/dmidecode.c b/dmidecode.c >> index f41c85b..b7b03dd 100644 >> --- a/dmidecode.c >> +++ b/dmidecode.c >> @@ -4599,7 +4599,7 @@ static int smbios3_decode(u8 *buf, const char *devmem, >> u32 flags) >> } >> >> dmi_table(((off_t)offset.h << 32) | offset.l, >> - WORD(buf + 0x0C), 0, ver, devmem, flags | FLAG_STOP_AT_EOT); >> + DWORD(buf + 0x0C), 0, ver, devmem, flags | FLAG_STOP_AT_EOT); >> >> if (opt.flags & FLAG_DUMP_BIN) >> { > > Good catch! Applied, thanks. > > Out of curiosity, did you find this bug by code analysis or do you > actually have a system where the maximum table size doesn't fit on 32 > bits? >
Yes, I meet this issue indeed. May be our BIOS team give the wrong size value (about 10M). And I have another problem about kernel: If the size is bigger than 256K, I'll get a WARN_ON. It's failed to decode SMBIOS 3, but fallback to decode SMBIOS 2.8. [ 0.000000] WARNING: at arch/x86/mm/ioremap.c:536 __early_ioremap+0x11c/0x1bf() [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-229.20.1.test.x86_64 #1 [ 0.000000] 0000000000000000 4ebb1c6aa8f3027c ffffffff818fbd78 ffffffff815ff6f8 [ 0.000000] ffffffff818fbdb0 ffffffff8106ef3b 0000000000000000 000000006b791000 [ 0.000000] 0000000000000001 0000000000000000 0000000000000001 ffffffff818fbdc0 [ 0.000000] Call Trace: [ 0.000000] [<ffffffff815ff6f8>] dump_stack+0x19/0x1b [ 0.000000] [<ffffffff8106ef3b>] warn_slowpath_common+0x6b/0xb0 [ 0.000000] [<ffffffff8106f08a>] warn_slowpath_null+0x1a/0x20 [ 0.000000] [<ffffffff81a5834b>] __early_ioremap+0x11c/0x1bf [ 0.000000] [<ffffffff81a89f76>] ? dmi_save_one_device+0x78/0x78 [ 0.000000] [<ffffffff81a585d4>] early_ioremap+0x13/0x15 [ 0.000000] [<ffffffff81a89d70>] dmi_walk_early+0x1c/0x67 [ 0.000000] [<ffffffff81a8a732>] dmi_smbios3_present+0x89/0xe5 [ 0.000000] [<ffffffff81a8a856>] dmi_scan_machine+0x78/0x1bc [ 0.000000] [<ffffffff81a4457e>] setup_arch+0x471/0xe86 [ 0.000000] [<ffffffff81a3dd0c>] start_kernel+0xde/0x44a [ 0.000000] [<ffffffff81a3d120>] ? early_idt_handlers+0x120/0x120 [ 0.000000] [<ffffffff81a3d5ee>] x86_64_start_reservations+0x2a/0x2c [ 0.000000] [<ffffffff81a3d742>] x86_64_start_kernel+0x152/0x175 [ 0.000000] ---[ end trace a7919e7f17c0a725 ]--- Do you have any better idea to fix this problem if the max size is bigger than 256K? The dmi table may be very large in big numa system. Thanks, Xie XiuQi _______________________________________________ https://lists.nongnu.org/mailman/listinfo/dmidecode-devel
