On Monday, July 07, 2014 03:38:53 PM Paul Gortmaker wrote:
> If one looks at acpi_os_read_port() it is very similar to the
> acpi_os_read_memory() aside from the underlying I/O method.
> However we zero out the u32 in the former and not in the latter,
> when it seems prudent to do so in both.
>
> This was found by quasi-random code inspection, and as such there
> is no known symptom or bug to associate with possibly having stale
> data in the high bits of "value".
I'm actually afraid that this may lead to regressions, because the caller's
intention may be to leave the higher bits untouched. So I'd think some audit
of the existing callers would be necessary before making this change.
> Signed-off-by: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
> ---
> drivers/acpi/osl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index bad25b070fe0..a7373f1f31c8 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -953,6 +953,7 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u64 *value, u32 width)
> if (!value)
> value = &dummy;
>
> + *value = 0;
> switch (width) {
> case 8:
> *(u8 *) value = readb(virt_addr);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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
