[PATCH 0/3] ACPI Fixes for Hotplug

[PATCH 0/3] ACPI Fixes for Hotplug

[Joerg Roedel]

Hi,

here are fixes for three issues I found in ACPI code during
hotplug testing. Patches 2 and 3 fix the same issue, but I
think both make sense on their own.

Please review.

Thanks,

	Joerg

Joerg Roedel (3):
  ACPI, ioapic: Clear on-stack resource before using it
  ACPI: Remove platform devices from a bus on removal
  ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

 drivers/acpi/acpi_platform.c |  8 +++++---
 drivers/acpi/ioapic.c        |  6 ++++++
 drivers/acpi/scan.c          | 26 ++++++++++++++++++++++++++
 3 files changed, 37 insertions(+), 3 deletions(-)

-- 
1.9.1

[PATCH 1/3] ACPI, ioapic: Clear on-stack resource before using it

[Joerg Roedel]

From: Joerg Roedel <jroedel@suse.de>

The on-stack resource-window 'win' in setup_res() is not
properly initialized. This causes the pointers in the
embedded 'struct resource' to contain stale pointers.

These pointers (in my case the ->child pointer) gets later
propagated to the global iomem_resources list, causing a #GP
exception when the list is traversed in
iomem_map_sanity_check().

Fixes: c183619b63ec ('x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/acpi/ioapic.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index 1120dfd6..7e4fbf9 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -45,6 +45,12 @@ static acpi_status setup_res(struct acpi_resource *acpi_res, void *data)
 	struct resource *res = data;
 	struct resource_win win;
 
+	/*
+	 * We might assign this to 'res' later, make sure all pointers are
+	 * cleared before the resource is added to the global list
+	 */
+	memset(&win, 0, sizeof(win));
+
 	res->flags = 0;
 	if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM))
 		return AE_OK;
-- 
1.9.1

[PATCH 2/3] ACPI: Remove platform devices from a bus on removal

[Joerg Roedel]

From: Joerg Roedel <jroedel@suse.de>

The function acpi_bus_attach() creates platform_devices if
this is specified by the firmware. But in acpi_bus_trim()
these devices are not removed, leaving a dangling reference
to the parent device.

In the case of a PCI root-bus, this results in the
host_bridge device not being released on hot-remove.

Fix it by scanning the list of platform_devices for devices
to be removed with the bus.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/acpi/scan.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1926918..b07518b 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -13,6 +13,7 @@
 #include <linux/dmi.h>
 #include <linux/nls.h>
 #include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
 
 #include <asm/pgtable.h>
 
@@ -1928,6 +1929,25 @@ int acpi_bus_scan(acpi_handle handle)
 EXPORT_SYMBOL(acpi_bus_scan);
 
 /**
+ * acpi_bus_trim_platform_device - Check and remove a platform device
+ *				   from a bus
+ * @dev: Platform device to check
+ * @data: pointer to the acpi_device to check dev against
+ *
+ * Checks whether the platform_device dev belongs to the acpi_device
+ * data and unregisters dev if it matches.
+ */
+static int acpi_bus_trim_platform_device(struct device *dev, void *data)
+{
+	struct acpi_device *adev = data;
+
+	if (dev->fwnode == acpi_fwnode_handle(adev))
+		platform_device_unregister(to_platform_device(dev));
+
+	return 0;
+}
+
+/**
  * acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
  * @adev: Root of the ACPI namespace scope to walk.
  *
@@ -1950,6 +1970,12 @@ void acpi_bus_trim(struct acpi_device *adev)
 	} else {
 		device_release_driver(&adev->dev);
 	}
+
+	/* Remove platform devices from the bus */
+	if (adev->pnp.type.platform_id)
+		bus_for_each_dev(&platform_bus_type, NULL, adev,
+				 acpi_bus_trim_platform_device);
+
 	/*
 	 * Most likely, the device is going away, so put it into D3cold before
 	 * that.
-- 
1.9.1

Re: [PATCH 2/3] ACPI: Remove platform devices from a bus on removal

[joeyli]

On Wed, Mar 22, 2017 at 06:33:24PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> The function acpi_bus_attach() creates platform_devices if
> this is specified by the firmware. But in acpi_bus_trim()
> these devices are not removed, leaving a dangling reference
> to the parent device.
> 
> In the case of a PCI root-bus, this results in the
> host_bridge device not being released on hot-remove.
> 
> Fix it by scanning the list of platform_devices for devices
> to be removed with the bus.
> 
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> ---
>  drivers/acpi/scan.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 1926918..b07518b 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -13,6 +13,7 @@
>  #include <linux/dmi.h>
>  #include <linux/nls.h>
>  #include <linux/dma-mapping.h>
> +#include <linux/platform_device.h>
>  
>  #include <asm/pgtable.h>
>  
> @@ -1928,6 +1929,25 @@ int acpi_bus_scan(acpi_handle handle)
>  EXPORT_SYMBOL(acpi_bus_scan);
>  
>  /**
> + * acpi_bus_trim_platform_device - Check and remove a platform device
> + *				   from a bus
> + * @dev: Platform device to check
> + * @data: pointer to the acpi_device to check dev against
> + *
> + * Checks whether the platform_device dev belongs to the acpi_device
> + * data and unregisters dev if it matches.
> + */
> +static int acpi_bus_trim_platform_device(struct device *dev, void *data)
> +{
> +	struct acpi_device *adev = data;
> +
> +	if (dev->fwnode == acpi_fwnode_handle(adev))
> +		platform_device_unregister(to_platform_device(dev));
> +
> +	return 0;
> +}
> +
> +/**
>   * acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
>   * @adev: Root of the ACPI namespace scope to walk.
>   *
> @@ -1950,6 +1970,12 @@ void acpi_bus_trim(struct acpi_device *adev)
>  	} else {
>  		device_release_driver(&adev->dev);
>  	}
> +
> +	/* Remove platform devices from the bus */
> +	if (adev->pnp.type.platform_id)

This patch cases that dock_notify() is broken in find_dock_station()
because the dock_station platform device was removed.

If anyone wants to apply this patch, then the dock device should be
excluded:

+	if (is_dock_device(adev) && adev->pnp.type.platform_id)

> +		bus_for_each_dev(&platform_bus_type, NULL, adev,
> +				 acpi_bus_trim_platform_device);
> +
>  	/*
>  	 * Most likely, the device is going away, so put it into D3cold before
>  	 * that.

Thanks a lot!
Joey Lee

Re: [PATCH 2/3] ACPI: Remove platform devices from a bus on removal

[joeyli]

On Wed, Apr 19, 2017 at 02:50:17PM +0800, joeyli wrote:
> On Wed, Mar 22, 2017 at 06:33:24PM +0100, Joerg Roedel wrote:
> > From: Joerg Roedel <jroedel@suse.de>
> > 
> > The function acpi_bus_attach() creates platform_devices if
> > this is specified by the firmware. But in acpi_bus_trim()
> > these devices are not removed, leaving a dangling reference
> > to the parent device.
> > 
> > In the case of a PCI root-bus, this results in the
> > host_bridge device not being released on hot-remove.
> > 
> > Fix it by scanning the list of platform_devices for devices
> > to be removed with the bus.
> > 
> > Signed-off-by: Joerg Roedel <jroedel@suse.de>
> > ---
> >  drivers/acpi/scan.c | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 1926918..b07518b 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -13,6 +13,7 @@
> >  #include <linux/dmi.h>
> >  #include <linux/nls.h>
> >  #include <linux/dma-mapping.h>
> > +#include <linux/platform_device.h>
> >  
> >  #include <asm/pgtable.h>
> >  
> > @@ -1928,6 +1929,25 @@ int acpi_bus_scan(acpi_handle handle)
> >  EXPORT_SYMBOL(acpi_bus_scan);
> >  
> >  /**
> > + * acpi_bus_trim_platform_device - Check and remove a platform device
> > + *				   from a bus
> > + * @dev: Platform device to check
> > + * @data: pointer to the acpi_device to check dev against
> > + *
> > + * Checks whether the platform_device dev belongs to the acpi_device
> > + * data and unregisters dev if it matches.
> > + */
> > +static int acpi_bus_trim_platform_device(struct device *dev, void *data)
> > +{
> > +	struct acpi_device *adev = data;
> > +
> > +	if (dev->fwnode == acpi_fwnode_handle(adev))
> > +		platform_device_unregister(to_platform_device(dev));
> > +
> > +	return 0;
> > +}
> > +
> > +/**
> >   * acpi_bus_trim - Detach scan handlers and drivers from ACPI device objects.
> >   * @adev: Root of the ACPI namespace scope to walk.
> >   *
> > @@ -1950,6 +1970,12 @@ void acpi_bus_trim(struct acpi_device *adev)
> >  	} else {
> >  		device_release_driver(&adev->dev);
> >  	}
> > +
> > +	/* Remove platform devices from the bus */
> > +	if (adev->pnp.type.platform_id)
> 
> This patch cases that dock_notify() is broken in find_dock_station()
> because the dock_station platform device was removed.
> 
> If anyone wants to apply this patch, then the dock device should be
> excluded:
> 
> +	if (is_dock_device(adev) && adev->pnp.type.platform_id)

Sorry, it should be:
+	if (!is_dock_device(adev) && adev->pnp.type.platform_id)

> 
> > +		bus_for_each_dev(&platform_bus_type, NULL, adev,
> > +				 acpi_bus_trim_platform_device);
> > +
> >  	/*
> >  	 * Most likely, the device is going away, so put it into D3cold before
> >  	 * that.
>

Joey Lee 

[PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Joerg Roedel]

From: Joerg Roedel <jroedel@suse.de>

No platform-device is required for IO(x)APICs, so don't even
create them.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
 drivers/acpi/acpi_platform.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index b4c1a6a..03250e1 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -25,9 +25,11 @@
 ACPI_MODULE_NAME("platform");
 
 static const struct acpi_device_id forbidden_id_list[] = {
-	{"PNP0000", 0},	/* PIC */
-	{"PNP0100", 0},	/* Timer */
-	{"PNP0200", 0},	/* AT DMA Controller */
+	{"PNP0000",  0},	/* PIC */
+	{"PNP0100",  0},	/* Timer */
+	{"PNP0200",  0},	/* AT DMA Controller */
+	{"ACPI0009", 0},	/* IOxAPIC */
+	{"ACPI000A", 0},	/* IOAPIC */
 	{"", 0},
 };
 
-- 
1.9.1

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Rafael J. Wysocki]

On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
> 
> No platform-device is required for IO(x)APICs, so don't even
> create them.
> 
> Signed-off-by: Joerg Roedel <jroedel@suse.de>

If we do this, I'd prefer not to do [2/3], because we'll introduce code that
will be essentially dead then.

> ---
>  drivers/acpi/acpi_platform.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index b4c1a6a..03250e1 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -25,9 +25,11 @@
>  ACPI_MODULE_NAME("platform");
>  
>  static const struct acpi_device_id forbidden_id_list[] = {
> -	{"PNP0000", 0},	/* PIC */
> -	{"PNP0100", 0},	/* Timer */
> -	{"PNP0200", 0},	/* AT DMA Controller */

Why do you change the existing entries?

> +	{"PNP0000",  0},	/* PIC */
> +	{"PNP0100",  0},	/* Timer */
> +	{"PNP0200",  0},	/* AT DMA Controller */
> +	{"ACPI0009", 0},	/* IOxAPIC */
> +	{"ACPI000A", 0},	/* IOAPIC */
>  	{"", 0},
>  };
>  
> 

Thanks,
Rafael

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Joerg Roedel]

Hi Rafael,

On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote:
> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote:
> > From: Joerg Roedel <jroedel@suse.de>
> > 
> > No platform-device is required for IO(x)APICs, so don't even
> > create them.
> > 
> > Signed-off-by: Joerg Roedel <jroedel@suse.de>
> 
> If we do this, I'd prefer not to do [2/3], because we'll introduce code that
> will be essentially dead then.

In this case the code in acpi_bus_attach() adding platform_devices is also
dead. Could it be removed then?

> 
> > ---
> >  drivers/acpi/acpi_platform.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> > index b4c1a6a..03250e1 100644
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -25,9 +25,11 @@
> >  ACPI_MODULE_NAME("platform");
> >  
> >  static const struct acpi_device_id forbidden_id_list[] = {
> > -	{"PNP0000", 0},	/* PIC */
> > -	{"PNP0100", 0},	/* Timer */
> > -	{"PNP0200", 0},	/* AT DMA Controller */
> 
> Why do you change the existing entries?

Just to align the '0's in one column :)


	Joerg

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Rafael J. Wysocki]

On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel <jroedel@suse.de> wrote:
> Hi Rafael,
>
> On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote:
>> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote:
>> > From: Joerg Roedel <jroedel@suse.de>
>> >
>> > No platform-device is required for IO(x)APICs, so don't even
>> > create them.
>> >
>> > Signed-off-by: Joerg Roedel <jroedel@suse.de>
>>
>> If we do this, I'd prefer not to do [2/3], because we'll introduce code that
>> will be essentially dead then.
>
> In this case the code in acpi_bus_attach() adding platform_devices is also
> dead. Could it be removed then?

It is not dead.

Platform devices are actually created by it, but they never go away.

Thanks,
Rafael

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Rafael J. Wysocki]

On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel <jroedel@suse.de> wrote:
>> Hi Rafael,
>>
>> On Wed, Mar 22, 2017 at 06:42:39PM +0100, Rafael J. Wysocki wrote:
>>> On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote:
>>> > From: Joerg Roedel <jroedel@suse.de>
>>> >
>>> > No platform-device is required for IO(x)APICs, so don't even
>>> > create them.
>>> >
>>> > Signed-off-by: Joerg Roedel <jroedel@suse.de>
>>>
>>> If we do this, I'd prefer not to do [2/3], because we'll introduce code that
>>> will be essentially dead then.
>>
>> In this case the code in acpi_bus_attach() adding platform_devices is also
>> dead. Could it be removed then?
>
> It is not dead.
>
> Platform devices are actually created by it, but they never go away.

IOW, they should never be created for anything hot-removable.

If they are, this is a bug (as you noticed).

Thanks,
Rafael

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Joerg Roedel]

On Thu, Mar 23, 2017 at 12:44:18AM +0100, Rafael J. Wysocki wrote:
> On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > It is not dead.
> >
> > Platform devices are actually created by it, but they never go away.
> 
> IOW, they should never be created for anything hot-removable.
> 
> If they are, this is a bug (as you noticed).

Okay, in this case patch 2 can be omitted.

But for my understanding, platform_devices created in acpi_bus_attach()
that are not hot-removable don't take a reference to the host_bridge,
right (at least when the host-bridge is hot-removable)?

Otherwise this would be a leak again in case the host-bridge gets
removed.


	Joerg

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Rafael J. Wysocki]

On Thu, Mar 23, 2017 at 12:58 AM, Joerg Roedel <joro@8bytes.org> wrote:
> On Thu, Mar 23, 2017 at 12:44:18AM +0100, Rafael J. Wysocki wrote:
>> On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> >
>> > It is not dead.
>> >
>> > Platform devices are actually created by it, but they never go away.
>>
>> IOW, they should never be created for anything hot-removable.
>>
>> If they are, this is a bug (as you noticed).
>
> Okay, in this case patch 2 can be omitted.
>
> But for my understanding, platform_devices created in acpi_bus_attach()
> that are not hot-removable don't take a reference to the host_bridge,
> right (at least when the host-bridge is hot-removable)?

They shouldn't.

> Otherwise this would be a leak again in case the host-bridge gets
> removed.

Right.

The main problem is that representing anything hot-removable as a
platform device is inherently fragile, as the platform bus type has no
idea whatever about things that may physically go away and platform
drivers don't expect that devices may vanish from under them in
general and so on.  Unregistration alone doesn't help much with that,
so IMO at least for now it's better to avoid using platform_device for
hot-removable stuff.

Thanks,
Rafael

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Joerg Roedel]

On Thu, Mar 23, 2017 at 02:06:44AM +0100, Rafael J. Wysocki wrote:
> The main problem is that representing anything hot-removable as a
> platform device is inherently fragile, as the platform bus type has no
> idea whatever about things that may physically go away and platform
> drivers don't expect that devices may vanish from under them in
> general and so on.  Unregistration alone doesn't help much with that,
> so IMO at least for now it's better to avoid using platform_device for
> hot-removable stuff.

Okay, thanks for the explanation. So patch 2 could be dropped, should I
resend without that patch or do you want to pick them up from this post?


	Joerg

Re: [PATCH 3/3] ACPI: Don't create a platform_device for IOAPIC/IOxAPIC

[Rafael J. Wysocki]

On Thu, Mar 23, 2017 at 11:50 AM, Joerg Roedel <jroedel@suse.de> wrote:
> On Thu, Mar 23, 2017 at 02:06:44AM +0100, Rafael J. Wysocki wrote:
>> The main problem is that representing anything hot-removable as a
>> platform device is inherently fragile, as the platform bus type has no
>> idea whatever about things that may physically go away and platform
>> drivers don't expect that devices may vanish from under them in
>> general and so on.  Unregistration alone doesn't help much with that,
>> so IMO at least for now it's better to avoid using platform_device for
>> hot-removable stuff.
>
> Okay, thanks for the explanation. So patch 2 could be dropped, should I
> resend without that patch or do you want to pick them up from this post?

I can pick them up easily enough, thanks!

Take care,
Rafael