Hi Jean,
On 2012/6/13 16:46, Jean Delvare wrote:
> Hi Xiao,
>
> On Wed, 13 Jun 2012 15:39:44 +0800, Xiao, Hui wrote:
>> Fix the incorrect bit width + offset check condition in apei_check_gar()
>> function introduced by commit v3.3-5-g15afae6.
>>
>> The bug caused regression on EINJ error injection with errors:
>>
>> [Firmware Bug]: APEI: Invalid bit width + offset in GAR [0x1121a5000/64/0/3/0]
>>
>> on a valid address region of:
>> - Register bit width: 64 bits
>> - Register bit offset: 0
>> - Access Size: 03 [DWord Access: 32]
>
> I don't see how this is valid, sorry. If you have a 64-bit register,
> you want 64-bit access, don't you?
>
Ideally yes. But I don't think if there is a 64-bit width register and only
lower 32-bit access authority given will make this region invalid.
Assuming a 64-bit register but only lower 32-bit is writable.
> If the access code is supposed to be able to read large registers in
> smaller chunks and assemble them transparently to a larger value, then
> there is no point in having any check at all, everything is valid. If
> not, then the above is just as invalid as the firmware issue discussed
> in bug #43282.
>
Able to read large registers in smaller chunk, I think so and the register
bit width set the access boundary.
For "assemble them transparently to a larger value, then...", not quite
understand what you mean here....
>>
>> Signed-off-by: Xiao, Hui <hui.xiao@xxxxxxxxxxxxxxx>
>> Signed-off-by: Chen Gong <gong.chen@xxxxxxxxxxxxxxx>
>> ---
>> drivers/acpi/apei/apei-base.c | 7 +++++--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
>> index 5577762..95e07b2 100644
>> --- a/drivers/acpi/apei/apei-base.c
>> +++ b/drivers/acpi/apei/apei-base.c
>> @@ -586,9 +586,12 @@ static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr,
>> }
>> *access_bit_width = 1UL << (access_size_code + 2);
>>
>> - if ((bit_width + bit_offset) > *access_bit_width) {
>> + /* bit_width and bit_offset must be zero when addressing a data
>> + * structure. So just check for non-zero case here */
>> + if ((bit_width != 0 && *access_bit_width > bit_width) ||
>> + bit_offset > *access_bit_width) {
>
> I can't make any sense of this test, sorry. And it will trigger on
> valid cases, starting with the most frequent case where
> *access_bit_width == bit_width. So, nack.
>
The condition here is for checking invalid GAR. When
*access_bit_width == bit_width
I don't think my code will trigger the error. Instead, the original condition
will trigger the error once bit_offset != 0, which doesn't make sense.
Besides if addressing a data structure, per ACPI spec bit_width and bit_offset
must be zero, the original condition will always end with error even valid
access width is given.
>> pr_warning(FW_BUG APEI_PFX
>> - "Invalid bit width + offset in GAR [0x%llx/%u/%u/%u/%u]\n",
>> + "Invalid bit width or offset in GAR [0x%llx/%u/%u/%u/%u]\n",
>> *paddr, bit_width, bit_offset, access_size_code,
>> space_id);
>> return -EINVAL;
>
>
Thanks,
-Hui
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
