Re: [dmidecode] [PATCH] dmidecode: use DWORD for Structure table maximum size in SMBIOS3

[Xie XiuQi]

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 <address@hidden>
>> ---
>>  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