Re: [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
On Saturday, December 28, 2013 07:59:09 PM Greg Kroah-Hartman wrote: > On Fri, Dec 27, 2013 at 11:21:59PM +0100, Rafael J. Wysocki wrote: > > Hi Greg, > > > > The following series of 2 patches (patch [2/2] in particular) make changes > > needed to handle hot-removal of system container devices (represented by > > ACPI container and module device objects) on Fujitsu systems. Those devices > > represent things like CPU packages, so we need to be able to take care of > > them > > cleanly for things like in-the-field CPU socked replacement to work. > > > > The problem being addressed here is that on the systems in question the > > removal > > of container devices has to be carried out with the help of user space that > > needs to be notified of the container removal before the kernel attempts to > > offline any devices below the container (e.g. in the package represented by > > the > > container device object in the ACPI tables). However, our current code > > works > > the other way around and the entire thing is messed up. > > > > This patchset adds the bare bones of what's needed to address that issue > > and it > > should be possible to build on top of the code added by it in the future if > > need be. > > > > Patch [1/2] introduces a new demand_offline flag for struct > > acpi_hotplug_profile > > that makes acpi_scan_hot_remove() check the offline status of the device > > object's > > companion physical devices to start with and return -EBUSY if at least one > > of them > > is not offline. > > > > Patch [2/2] uses that flag to implement the container handling. The > > details are > > in the changelog, but that's how it works. > > > > During the initial namespace scan the container ACPI scan handler creates > > "physical" system container device under /sys/devices/system/container/ for > > each ACPI container object whose status is "present" at that time (the sysfs > > name of that device is the same as the sysfs name of the corresponding > > container object and they are linked to each other via the firmware_node and > > physical_node symbolic links, respectively). Those system container devices > > are initially online. > > > > The container ACPI scan handler has the demand_offline flag set in its > > hotplug > > profile, so when a container eject event happens, acpi_scan_hot_remove() > > will > > notice that the flag is set in the device object's scan handler and will > > check the online status of its "physical" companion device, which is online > > (that is the system container device the above paragraph is about). That > > will > > cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY > > to > > be returned by acpi_scan_hot_remove(). User space is expected to respond to > > that KOBJ_CHANGE by doing what's necessary to remove the container. > > > > To that end, it needs to offline the system container device through its > > online > > sysfs attribute (which is present, because the bus type for containers > > provides > > the online and offline callbacks). However, the offline for system > > container > > devices will only succeed if the physical devices right below the container > > (e.g. in the package represented by it) are all offline, so user space will > > have to offline those devices before attempting to offline the system > > container > > device itself. When finished, user space can trigger the container removal > > with the help of the eject sysfs attribute of the ACPI container object > > pointed > > to by the system container device's firmware_node link (this time the check > > in > > acpi_scan_hot_remove() will succeed, because the system container device in > > question is now offline). > > > > Please let me know if you have any objections. If not, I'd like to queue up > > these patches for 3.14. > > No objection from me, I've acked the second patch, feel free to take > both of them in your tree. I will, thanks a lot! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
On Saturday, December 28, 2013 07:59:09 PM Greg Kroah-Hartman wrote: On Fri, Dec 27, 2013 at 11:21:59PM +0100, Rafael J. Wysocki wrote: Hi Greg, The following series of 2 patches (patch [2/2] in particular) make changes needed to handle hot-removal of system container devices (represented by ACPI container and module device objects) on Fujitsu systems. Those devices represent things like CPU packages, so we need to be able to take care of them cleanly for things like in-the-field CPU socked replacement to work. The problem being addressed here is that on the systems in question the removal of container devices has to be carried out with the help of user space that needs to be notified of the container removal before the kernel attempts to offline any devices below the container (e.g. in the package represented by the container device object in the ACPI tables). However, our current code works the other way around and the entire thing is messed up. This patchset adds the bare bones of what's needed to address that issue and it should be possible to build on top of the code added by it in the future if need be. Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile that makes acpi_scan_hot_remove() check the offline status of the device object's companion physical devices to start with and return -EBUSY if at least one of them is not offline. Patch [2/2] uses that flag to implement the container handling. The details are in the changelog, but that's how it works. During the initial namespace scan the container ACPI scan handler creates physical system container device under /sys/devices/system/container/ for each ACPI container object whose status is present at that time (the sysfs name of that device is the same as the sysfs name of the corresponding container object and they are linked to each other via the firmware_node and physical_node symbolic links, respectively). Those system container devices are initially online. The container ACPI scan handler has the demand_offline flag set in its hotplug profile, so when a container eject event happens, acpi_scan_hot_remove() will notice that the flag is set in the device object's scan handler and will check the online status of its physical companion device, which is online (that is the system container device the above paragraph is about). That will cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to be returned by acpi_scan_hot_remove(). User space is expected to respond to that KOBJ_CHANGE by doing what's necessary to remove the container. To that end, it needs to offline the system container device through its online sysfs attribute (which is present, because the bus type for containers provides the online and offline callbacks). However, the offline for system container devices will only succeed if the physical devices right below the container (e.g. in the package represented by it) are all offline, so user space will have to offline those devices before attempting to offline the system container device itself. When finished, user space can trigger the container removal with the help of the eject sysfs attribute of the ACPI container object pointed to by the system container device's firmware_node link (this time the check in acpi_scan_hot_remove() will succeed, because the system container device in question is now offline). Please let me know if you have any objections. If not, I'd like to queue up these patches for 3.14. No objection from me, I've acked the second patch, feel free to take both of them in your tree. I will, thanks a lot! Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
On Fri, Dec 27, 2013 at 11:21:59PM +0100, Rafael J. Wysocki wrote: > Hi Greg, > > The following series of 2 patches (patch [2/2] in particular) make changes > needed to handle hot-removal of system container devices (represented by > ACPI container and module device objects) on Fujitsu systems. Those devices > represent things like CPU packages, so we need to be able to take care of them > cleanly for things like in-the-field CPU socked replacement to work. > > The problem being addressed here is that on the systems in question the > removal > of container devices has to be carried out with the help of user space that > needs to be notified of the container removal before the kernel attempts to > offline any devices below the container (e.g. in the package represented by > the > container device object in the ACPI tables). However, our current code works > the other way around and the entire thing is messed up. > > This patchset adds the bare bones of what's needed to address that issue and > it > should be possible to build on top of the code added by it in the future if > need be. > > Patch [1/2] introduces a new demand_offline flag for struct > acpi_hotplug_profile > that makes acpi_scan_hot_remove() check the offline status of the device > object's > companion physical devices to start with and return -EBUSY if at least one of > them > is not offline. > > Patch [2/2] uses that flag to implement the container handling. The details > are > in the changelog, but that's how it works. > > During the initial namespace scan the container ACPI scan handler creates > "physical" system container device under /sys/devices/system/container/ for > each ACPI container object whose status is "present" at that time (the sysfs > name of that device is the same as the sysfs name of the corresponding > container object and they are linked to each other via the firmware_node and > physical_node symbolic links, respectively). Those system container devices > are initially online. > > The container ACPI scan handler has the demand_offline flag set in its hotplug > profile, so when a container eject event happens, acpi_scan_hot_remove() will > notice that the flag is set in the device object's scan handler and will > check the online status of its "physical" companion device, which is online > (that is the system container device the above paragraph is about). That will > cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to > be returned by acpi_scan_hot_remove(). User space is expected to respond to > that KOBJ_CHANGE by doing what's necessary to remove the container. > > To that end, it needs to offline the system container device through its > online > sysfs attribute (which is present, because the bus type for containers > provides > the online and offline callbacks). However, the offline for system container > devices will only succeed if the physical devices right below the container > (e.g. in the package represented by it) are all offline, so user space will > have to offline those devices before attempting to offline the system > container > device itself. When finished, user space can trigger the container removal > with the help of the eject sysfs attribute of the ACPI container object > pointed > to by the system container device's firmware_node link (this time the check in > acpi_scan_hot_remove() will succeed, because the system container device in > question is now offline). > > Please let me know if you have any objections. If not, I'd like to queue up > these patches for 3.14. No objection from me, I've acked the second patch, feel free to take both of them in your tree. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
On Fri, Dec 27, 2013 at 11:21:59PM +0100, Rafael J. Wysocki wrote: Hi Greg, The following series of 2 patches (patch [2/2] in particular) make changes needed to handle hot-removal of system container devices (represented by ACPI container and module device objects) on Fujitsu systems. Those devices represent things like CPU packages, so we need to be able to take care of them cleanly for things like in-the-field CPU socked replacement to work. The problem being addressed here is that on the systems in question the removal of container devices has to be carried out with the help of user space that needs to be notified of the container removal before the kernel attempts to offline any devices below the container (e.g. in the package represented by the container device object in the ACPI tables). However, our current code works the other way around and the entire thing is messed up. This patchset adds the bare bones of what's needed to address that issue and it should be possible to build on top of the code added by it in the future if need be. Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile that makes acpi_scan_hot_remove() check the offline status of the device object's companion physical devices to start with and return -EBUSY if at least one of them is not offline. Patch [2/2] uses that flag to implement the container handling. The details are in the changelog, but that's how it works. During the initial namespace scan the container ACPI scan handler creates physical system container device under /sys/devices/system/container/ for each ACPI container object whose status is present at that time (the sysfs name of that device is the same as the sysfs name of the corresponding container object and they are linked to each other via the firmware_node and physical_node symbolic links, respectively). Those system container devices are initially online. The container ACPI scan handler has the demand_offline flag set in its hotplug profile, so when a container eject event happens, acpi_scan_hot_remove() will notice that the flag is set in the device object's scan handler and will check the online status of its physical companion device, which is online (that is the system container device the above paragraph is about). That will cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to be returned by acpi_scan_hot_remove(). User space is expected to respond to that KOBJ_CHANGE by doing what's necessary to remove the container. To that end, it needs to offline the system container device through its online sysfs attribute (which is present, because the bus type for containers provides the online and offline callbacks). However, the offline for system container devices will only succeed if the physical devices right below the container (e.g. in the package represented by it) are all offline, so user space will have to offline those devices before attempting to offline the system container device itself. When finished, user space can trigger the container removal with the help of the eject sysfs attribute of the ACPI container object pointed to by the system container device's firmware_node link (this time the check in acpi_scan_hot_remove() will succeed, because the system container device in question is now offline). Please let me know if you have any objections. If not, I'd like to queue up these patches for 3.14. No objection from me, I've acked the second patch, feel free to take both of them in your tree. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
Hi Greg, The following series of 2 patches (patch [2/2] in particular) make changes needed to handle hot-removal of system container devices (represented by ACPI container and module device objects) on Fujitsu systems. Those devices represent things like CPU packages, so we need to be able to take care of them cleanly for things like in-the-field CPU socked replacement to work. The problem being addressed here is that on the systems in question the removal of container devices has to be carried out with the help of user space that needs to be notified of the container removal before the kernel attempts to offline any devices below the container (e.g. in the package represented by the container device object in the ACPI tables). However, our current code works the other way around and the entire thing is messed up. This patchset adds the bare bones of what's needed to address that issue and it should be possible to build on top of the code added by it in the future if need be. Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile that makes acpi_scan_hot_remove() check the offline status of the device object's companion physical devices to start with and return -EBUSY if at least one of them is not offline. Patch [2/2] uses that flag to implement the container handling. The details are in the changelog, but that's how it works. During the initial namespace scan the container ACPI scan handler creates "physical" system container device under /sys/devices/system/container/ for each ACPI container object whose status is "present" at that time (the sysfs name of that device is the same as the sysfs name of the corresponding container object and they are linked to each other via the firmware_node and physical_node symbolic links, respectively). Those system container devices are initially online. The container ACPI scan handler has the demand_offline flag set in its hotplug profile, so when a container eject event happens, acpi_scan_hot_remove() will notice that the flag is set in the device object's scan handler and will check the online status of its "physical" companion device, which is online (that is the system container device the above paragraph is about). That will cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to be returned by acpi_scan_hot_remove(). User space is expected to respond to that KOBJ_CHANGE by doing what's necessary to remove the container. To that end, it needs to offline the system container device through its online sysfs attribute (which is present, because the bus type for containers provides the online and offline callbacks). However, the offline for system container devices will only succeed if the physical devices right below the container (e.g. in the package represented by it) are all offline, so user space will have to offline those devices before attempting to offline the system container device itself. When finished, user space can trigger the container removal with the help of the eject sysfs attribute of the ACPI container object pointed to by the system container device's firmware_node link (this time the check in acpi_scan_hot_remove() will succeed, because the system container device in question is now offline). Please let me know if you have any objections. If not, I'd like to queue up these patches for 3.14. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] ACPI / hotplug / driver core: Special handling for container devices
Hi Greg, The following series of 2 patches (patch [2/2] in particular) make changes needed to handle hot-removal of system container devices (represented by ACPI container and module device objects) on Fujitsu systems. Those devices represent things like CPU packages, so we need to be able to take care of them cleanly for things like in-the-field CPU socked replacement to work. The problem being addressed here is that on the systems in question the removal of container devices has to be carried out with the help of user space that needs to be notified of the container removal before the kernel attempts to offline any devices below the container (e.g. in the package represented by the container device object in the ACPI tables). However, our current code works the other way around and the entire thing is messed up. This patchset adds the bare bones of what's needed to address that issue and it should be possible to build on top of the code added by it in the future if need be. Patch [1/2] introduces a new demand_offline flag for struct acpi_hotplug_profile that makes acpi_scan_hot_remove() check the offline status of the device object's companion physical devices to start with and return -EBUSY if at least one of them is not offline. Patch [2/2] uses that flag to implement the container handling. The details are in the changelog, but that's how it works. During the initial namespace scan the container ACPI scan handler creates physical system container device under /sys/devices/system/container/ for each ACPI container object whose status is present at that time (the sysfs name of that device is the same as the sysfs name of the corresponding container object and they are linked to each other via the firmware_node and physical_node symbolic links, respectively). Those system container devices are initially online. The container ACPI scan handler has the demand_offline flag set in its hotplug profile, so when a container eject event happens, acpi_scan_hot_remove() will notice that the flag is set in the device object's scan handler and will check the online status of its physical companion device, which is online (that is the system container device the above paragraph is about). That will cause KOBJ_CHANGE to be emitted for the system container device and -EBUSY to be returned by acpi_scan_hot_remove(). User space is expected to respond to that KOBJ_CHANGE by doing what's necessary to remove the container. To that end, it needs to offline the system container device through its online sysfs attribute (which is present, because the bus type for containers provides the online and offline callbacks). However, the offline for system container devices will only succeed if the physical devices right below the container (e.g. in the package represented by it) are all offline, so user space will have to offline those devices before attempting to offline the system container device itself. When finished, user space can trigger the container removal with the help of the eject sysfs attribute of the ACPI container object pointed to by the system container device's firmware_node link (this time the check in acpi_scan_hot_remove() will succeed, because the system container device in question is now offline). Please let me know if you have any objections. If not, I'd like to queue up these patches for 3.14. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
