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
From: Joerg Roedel <[email protected]>
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 <[email protected]>
---
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
From: Joerg Roedel <[email protected]>
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 <[email protected]>
---
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
From: Joerg Roedel <[email protected]>
No platform-device is required for IO(x)APICs, so don't even
create them.
Signed-off-by: Joerg Roedel <[email protected]>
---
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
On Wednesday, March 22, 2017 06:33:25 PM Joerg Roedel wrote:
> From: Joerg Roedel <[email protected]>
>
> No platform-device is required for IO(x)APICs, so don't even
> create them.
>
> Signed-off-by: Joerg Roedel <[email protected]>
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
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 <[email protected]>
> >
> > No platform-device is required for IO(x)APICs, so don't even
> > create them.
> >
> > Signed-off-by: Joerg Roedel <[email protected]>
>
> 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
On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel <[email protected]> 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 <[email protected]>
>> >
>> > No platform-device is required for IO(x)APICs, so don't even
>> > create them.
>> >
>> > Signed-off-by: Joerg Roedel <[email protected]>
>>
>> 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
On Thu, Mar 23, 2017 at 12:41 AM, Rafael J. Wysocki <[email protected]> wrote:
> On Wed, Mar 22, 2017 at 11:58 PM, Joerg Roedel <[email protected]> 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 <[email protected]>
>>> >
>>> > No platform-device is required for IO(x)APICs, so don't even
>>> > create them.
>>> >
>>> > Signed-off-by: Joerg Roedel <[email protected]>
>>>
>>> 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
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 <[email protected]> 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
On Thu, Mar 23, 2017 at 12:58 AM, Joerg Roedel <[email protected]> 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 <[email protected]> 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
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
On Thu, Mar 23, 2017 at 11:50 AM, Joerg Roedel <[email protected]> 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
On Wed, Mar 22, 2017 at 06:33:24PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <[email protected]>
>
> 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 <[email protected]>
> ---
> 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
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 <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > 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