Re: [PATCH v3] ACPI: scan: Avoid registering platform devices with resource overlaps

Paul Menzel <[email protected]>
Newsgroups org.kernel.vger.linux-integrity,org.kernel.vger.linux-acpi,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Dear Rafael,


Thank you for the patch.

Am 07.08.26 um 12:22 schrieb Rafael J. Wysocki:
> From: "Rafael J. Wysocki" <[email protected]>
> 
> If acpi_dev_get_resources() returns overlapping I/O or memory resources,
> the subsequent registration of a platform device will fail with -EBUSY
> due to a resource conflict.  This is reported to happen on Acer Aspire
> ES1-572 [1].

Reading the diff, it might be useful to paste the log warning already here:

     tpm_crb_acpi MSFT0101:00: [Firmware Bug]: Bad ACPI memory layout

> Avoid that by adjusting resources returned by acpi_dev_get_resources()
> to eliminate partial overlaps between them.
> 
> This has not been regarded as necessary before because putting
> overlapping resources into the _CRS of one device is really pointless,
> but now that the issue has been reported to actually happen in the
> field, it needs to be done.
> 
> Fixes: ab06eb920401 ("ACPI: scan: Register platform devices for fixed event buttons")
> Reported-by: Julien <[email protected]>
> Closes: https://lore.kernel.org/linux-integrity/CAJOGg3z6LJPDsdPNBxajgy8_wQxfhYBRxe4EiurZf3kPU5A5Bw@mail.gmail.com/ [1]
> Cc: All applicable <[email protected]>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
> 
> v2 -> v3:
>     * Use resource_union() and adjust code and comment (Andy)
>     * Include ioport.h directly
> 
> v1 -> v2:
>     * Add the expanded resource instead of and not in addition to the other
>       overlapping one (Sashiko)
> 
> ---
>   drivers/acpi/acpi_platform.c |   39 +++++++++++++++++++++++++++++++++++++--
>   1 file changed, 37 insertions(+), 2 deletions(-)
> 
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -12,6 +12,7 @@
>   #include <linux/bits.h>
>   #include <linux/device.h>
>   #include <linux/err.h>
> +#include <linux/ioport.h>
>   #include <linux/kernel.h>
>   #include <linux/module.h>
>   #include <linux/dma-mapping.h>
> @@ -71,6 +72,36 @@ static struct notifier_block acpi_platfo
>   	.notifier_call = acpi_platform_device_remove_notify,
>   };
>   
> +static unsigned int acpi_platform_adjust_resources(struct acpi_device *adev,
> +						   struct resource *new_res,
> +						   struct resource *resources,
> +						   unsigned int count)
> +{
> +	unsigned int i;
> +
> +	if (!(new_res->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
> +		return count;
> +
> +	for (i = 0; i < count; ) {
> +		struct resource *res = &resources[i];
> +
> +		if (resource_type(new_res) != resource_type(res) ||
> +		    !resource_union(new_res, res, new_res)) {
> +			i++;
> +			continue;
> +		}
> +
> +		dev_info(&adev->dev, "%pR expanded to avoid overlap\n", new_res);

Maybe more normal user understandable:

     %pR expanded to fit all resources to avoid overlap

For the record, Julian reported that now the lines below are logged:

     MSFT0101:00: [mem 0xfed40000-0xfed4103f] expanded to avoid overlap
     tpm_crb_acpi MSFT0101:00: [Firmware Bug]: Bad ACPI memory layout

> +		/*
> +		 * Eliminate the previously processed resource that overlapped
> +		 * with the new one because it is not necessary any more.
> +		 */
> +		memmove(res, res + 1, (--count - i) * sizeof(*res));
> +	}
> +
> +	return count;
> +}
> +
>   static void acpi_platform_fill_resource(struct acpi_device *adev,
>   	const struct resource *src, struct resource *dest)
>   {
> @@ -151,10 +182,14 @@ struct platform_device *acpi_create_plat
>   				return ERR_PTR(-ENOMEM);
>   			}
>   			count = 0;
> -			list_for_each_entry(rentry, &resource_list, node)
> +			list_for_each_entry(rentry, &resource_list, node) {
> +				count = acpi_platform_adjust_resources(adev,
> +								       rentry->res,
> +								       resources,
> +								       count);
>   				acpi_platform_fill_resource(adev, rentry->res,
>   							    &resources[count++]);
> -
> +			}
>   			acpi_dev_free_resource_list(&resource_list);
>   		}
>   	}

Reviewed-by: Paul Menzel <[email protected]>


Kind regards,

Paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.