On Fri, 2015-11-20 at 19:05 -0500, Linda Knippers wrote:
> The size of NFIT tables don't necessarily match the size of the
> data structures that we use for them. For example, the NVDIMM
> Control Region Structure table is shorter for a device with
> no block control windows than for a device with block control windows.
> Other tables, such as Flush Hint Address Structure and the Interleave
> Structure are variable length by definition.
>
> Account for the size difference when comparing table entries by
> using the actual table size from the table header if it's less
> than the structure size.
>
Agreed about the variable length tables - Flush Hint and Interleave. But
for the others, this makes it possible for a buggy bios implementation
to have a *really* small table - one that doesn't even have enough
fields to work - to pass the add_tables stage where it might have failed
previously.
I feel there may be need for an ACPI clarification for this specifying
whether if certain fields are irrelevant, they can be excluded entirely.
For example, the DCR wording is:
Number of Block Control Windows must match the
corresponding number of Block Data Windows. Fields that
follow this field are valid only if the number of Block Control
Windows is non-zero.
This leads me to believe that those fields should be 'present' but
ignored in the case of zero block windows.
If we make add_tables process only header.length and accept the
shortened table, there is nothing to tell future code that the structure
that piece of memory is casted to is a truncated one.
Thoughts?
-Vishal��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
