2020-01-03 04:56:35

by Chester Lin

[permalink] [raw]
Subject: [RFC PATCH v2 0/3] ACPI: New eject flow to remove devices cautiously

Currently there are two ways to handle ACPI device ejection. When an eject
event happens on a container, the kernel just sends KOBJ_CHANGE to
userland and userland should handle offline operation. For other device
types, acpi_scan_try_to_offline() is called and it tries to put target
device(s) offline and then removes all nodes once they are all offline.

However we found that sometimes applications could intensively access
resources on ejectable devices therefore they could have risk if ejection
suddenly happens and removes devices without any notification. In stead
of executing the offline callbakcs directly, we want to introduce a new
approach, which sends change events to notify all target nodes beforehand
and hands over offline handling to userland so that userland can have a
chance to schedule an offline task based on current workload. The online
function to recover from failure is also changed, it follows the same
approach to send change events rather than putting devices online directly
, which means userland will also need to take care of online handling.

To ensure that eject function can work properly since normal users might
not have their own offline/online handling, we will submit a generic udev
rule to systemd upstream as default in order to deal with change events
and take [offline/online] action accordingly. But the Hot-Removing part
still remains so the hotplug function can run to it once target nodes are
all offline.

To easily monitor eject status and start over an eject process, there's a
status trace mechanism in this eject flow, which helps to count current
online devices under the ejectable target, and it can reschedule an eject
event when all nodes within the device tree have been put offline.

v2:
- device_sysfs: Add descriptions in /Document/ABI/testing/sysfs-bus-acpi
- device_sysfs: Replace the declartion with DEVICE_ATTR_RW and add cancel
option in eject_store.
- scan: Add a retry mechanism when userspace fail to put device offline.
- scan: Add ready-to-remove state.

Chester Lin (3):
ACPI / hotplug: Send change events for offline/online requests when
eject is triggered
ACPI / hotplug: Eject status trace and auto-remove approach
ACPI / device_sysfs: Add eject_show and add a cancel option in
eject_store

Documentation/ABI/testing/sysfs-bus-acpi | 9 +-
drivers/acpi/container.c | 2 +-
drivers/acpi/device_sysfs.c | 94 ++++++-
drivers/acpi/glue.c | 146 +++++++++++
drivers/acpi/internal.h | 34 ++-
drivers/acpi/scan.c | 318 +++++++++++++++++------
drivers/base/core.c | 4 +
include/acpi/acpi_bus.h | 3 +-
include/linux/acpi.h | 6 +
9 files changed, 523 insertions(+), 93 deletions(-)

--
2.20.1


2020-01-03 04:56:46

by Chester Lin

[permalink] [raw]
Subject: [RFC PATCH v2 1/3] ACPI / hotplug: Send change events for offline/online requests when eject is triggered

Here we change offline/online handling in device hotplug by sending change
events to userland as notification so that userland can have control and
determine when will be a good time to put them offline/online based on
current workload. In this approach the real offline/online opertions are
handed over to userland so that userland can have more time to prepare
before any device change actually happens.

All child devices under the ejection target are traversed and notified
hierarchically based on ACPI namespace in ascending order when an eject
event happens.

Signed-off-by: Chester Lin <[email protected]>
---
drivers/acpi/container.c | 2 +-
drivers/acpi/internal.h | 2 +-
drivers/acpi/scan.c | 140 +++++++++++++++++----------------------
include/acpi/acpi_bus.h | 2 +-
4 files changed, 65 insertions(+), 81 deletions(-)

diff --git a/drivers/acpi/container.c b/drivers/acpi/container.c
index 9ea5f55d97e3..53ca9b1ae1bf 100644
--- a/drivers/acpi/container.c
+++ b/drivers/acpi/container.c
@@ -33,7 +33,7 @@ static int acpi_container_offline(struct container_dev *cdev)

/* Check all of the dependent devices' physical companions. */
list_for_each_entry(child, &adev->children, node)
- if (!acpi_scan_is_offline(child, false))
+ if (!acpi_scan_is_offline(child))
return -EBUSY;

return 0;
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index f6157d4d637a..656d237b073d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -83,7 +83,7 @@ void acpi_apd_init(void);
acpi_status acpi_hotplug_schedule(struct acpi_device *adev, u32 src);
bool acpi_queue_hotplug_work(struct work_struct *work);
void acpi_device_hotplug(struct acpi_device *adev, u32 src);
-bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent);
+bool acpi_scan_is_offline(struct acpi_device *adev);

acpi_status acpi_sysfs_table_handler(u32 event, void *table, void *context);
void acpi_scan_table_handler(u32 event, void *table, void *context);
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 0e28270b0fd8..d7628146eb5f 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -113,11 +113,10 @@ int acpi_scan_add_handler_with_hotplug(struct acpi_scan_handler *handler,
return 0;
}

-bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent)
+bool acpi_scan_is_offline(struct acpi_device *adev)
{
struct acpi_device_physical_node *pn;
bool offline = true;
- char *envp[] = { "EVENT=offline", NULL };

/*
* acpi_container_offline() calls this for all of the container's
@@ -127,9 +126,6 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent)

list_for_each_entry(pn, &adev->physical_node_list, node)
if (device_supports_offline(pn->dev) && !pn->dev->offline) {
- if (uevent)
- kobject_uevent_env(&pn->dev->kobj, KOBJ_CHANGE, envp);
-
offline = false;
break;
}
@@ -138,13 +134,12 @@ bool acpi_scan_is_offline(struct acpi_device *adev, bool uevent)
return offline;
}

-static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
- void **ret_p)
+static acpi_status acpi_bus_offline_notify(acpi_handle handle, u32 lvl,
+ void *data, void **ret_p)
{
struct acpi_device *device = NULL;
struct acpi_device_physical_node *pn;
- bool second_pass = (bool)data;
- acpi_status status = AE_OK;
+ char *envp[] = { "EVENT=offline", NULL };

if (acpi_bus_get_device(handle, &device))
return AE_OK;
@@ -155,100 +150,93 @@ static acpi_status acpi_bus_offline(acpi_handle handle, u32 lvl, void *data,
}

mutex_lock(&device->physical_node_lock);
-
list_for_each_entry(pn, &device->physical_node_list, node) {
- int ret;
-
- if (second_pass) {
- /* Skip devices offlined by the first pass. */
- if (pn->put_online)
- continue;
- } else {
- pn->put_online = false;
- }
- ret = device_offline(pn->dev);
- if (ret >= 0) {
- pn->put_online = !ret;
- } else {
- *ret_p = pn->dev;
- if (second_pass) {
- status = AE_ERROR;
- break;
- }
+ if (device_supports_offline(pn->dev) && !(pn->dev->offline)) {
+ kobject_uevent_env(&pn->dev->kobj, KOBJ_CHANGE, envp);
+ pn->changed_offline = true;
}
}
-
mutex_unlock(&device->physical_node_lock);

- return status;
+ return AE_OK;
}

-static acpi_status acpi_bus_online(acpi_handle handle, u32 lvl, void *data,
- void **ret_p)
+static acpi_status acpi_bus_online_notify(acpi_handle handle, u32 lvl,
+ void *data, void **ret_p)
{
struct acpi_device *device = NULL;
struct acpi_device_physical_node *pn;
+ char *envp[] = { "EVENT=online", NULL };

if (acpi_bus_get_device(handle, &device))
return AE_OK;

mutex_lock(&device->physical_node_lock);

- list_for_each_entry(pn, &device->physical_node_list, node)
- if (pn->put_online) {
- device_online(pn->dev);
- pn->put_online = false;
+ list_for_each_entry(pn, &device->physical_node_list, node) {
+ if (pn->changed_offline) {
+ kobject_uevent_env(&pn->dev->kobj, KOBJ_CHANGE, envp);
+ pn->changed_offline = false;
}
+ }

mutex_unlock(&device->physical_node_lock);
-
return AE_OK;
}

-static int acpi_scan_try_to_offline(struct acpi_device *device)
+static void acpi_scan_notify_online(struct acpi_device *device)
+{
+ acpi_handle handle = device->handle;
+
+ acpi_bus_online_notify(handle, 0, NULL, NULL);
+ acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
+ acpi_bus_online_notify, NULL, NULL, NULL);
+}
+
+static int acpi_scan_notify_offline(struct acpi_device *device)
{
acpi_handle handle = device->handle;
struct device *errdev = NULL;
acpi_status status;

- /*
- * Carry out two passes here and ignore errors in the first pass,
- * because if the devices in question are memory blocks and
- * CONFIG_MEMCG is set, one of the blocks may hold data structures
- * that the other blocks depend on, but it is not known in advance which
- * block holds them.
- *
- * If the first pass is successful, the second one isn't needed, though.
- */
status = acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- NULL, acpi_bus_offline, (void *)false,
- (void **)&errdev);
- if (status == AE_SUPPORT) {
+ NULL, acpi_bus_offline_notify,
+ NULL, (void **)&errdev);
+ if (errdev)
+ goto notify_error;
+
+ status = acpi_bus_offline_notify(handle, 0, NULL,
+ (void **)&errdev);
+
+ if (errdev)
+ goto notify_error;
+
+ return 0;
+
+notify_error:
+ acpi_scan_notify_online(device);
+
+ switch (status) {
+ case AE_SUPPORT:
dev_warn(errdev, "Offline disabled.\n");
- acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- acpi_bus_online, NULL, NULL, NULL);
return -EPERM;
+ default:
+ dev_warn(errdev, "Offline failed. (status:%#x)\n", status);
+ return -EBUSY;
}
- acpi_bus_offline(handle, 0, (void *)false, (void **)&errdev);
- if (errdev) {
- errdev = NULL;
- acpi_walk_namespace(ACPI_TYPE_ANY, handle, ACPI_UINT32_MAX,
- NULL, acpi_bus_offline, (void *)true,
- (void **)&errdev);
- if (!errdev)
- acpi_bus_offline(handle, 0, (void *)true,
- (void **)&errdev);
-
- if (errdev) {
- dev_warn(errdev, "Offline failed.\n");
- acpi_bus_online(handle, 0, NULL, NULL);
- acpi_walk_namespace(ACPI_TYPE_ANY, handle,
- ACPI_UINT32_MAX, acpi_bus_online,
- NULL, NULL, NULL);
+}
+
+static int acpi_scan_offline_check(struct acpi_device *device)
+{
+ int ret = 0;
+ /* Send offline request to userland if the container is not offline */
+ if (!acpi_scan_is_offline(device)) {
+ ret = acpi_scan_notify_offline(device);
+ if (!ret)
return -EBUSY;
- }
}
- return 0;
+
+ return ret;
}

static int acpi_scan_hot_remove(struct acpi_device *device)
@@ -256,15 +244,11 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
acpi_handle handle = device->handle;
unsigned long long sta;
acpi_status status;
+ int ret;

- if (device->handler && device->handler->hotplug.demand_offline) {
- if (!acpi_scan_is_offline(device, true))
- return -EBUSY;
- } else {
- int error = acpi_scan_try_to_offline(device);
- if (error)
- return error;
- }
+ ret = acpi_scan_offline_check(device);
+ if (ret)
+ return ret;

ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"Hot-removing device %s...\n", dev_name(&device->dev)));
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 4752ff0a9d9b..57e4ad0483ca 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -330,7 +330,7 @@ struct acpi_device_physical_node {
unsigned int node_id;
struct list_head node;
struct device *dev;
- bool put_online:1;
+ bool changed_offline:1;
};

struct acpi_device_properties {
--
2.20.1

2020-01-15 10:16:30

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: [RFC PATCH v2 1/3] ACPI / hotplug: Send change events for offline/online requests when eject is triggered

On Friday, January 3, 2020 5:40:09 AM CET Chester Lin wrote:
> Here we change offline/online handling in device hotplug by sending change
> events to userland as notification so that userland can have control and
> determine when will be a good time to put them offline/online based on
> current workload. In this approach the real offline/online opertions are
> handed over to userland so that userland can have more time to prepare
> before any device change actually happens.
>
> All child devices under the ejection target are traversed and notified
> hierarchically based on ACPI namespace in ascending order when an eject
> event happens.
>
> Signed-off-by: Chester Lin <[email protected]>

So you replace the old flow with the new one and make the new one mandatory AFAICS.

Thus if anyone has relied on the old flow, they now need to switch over.

This is unfriendly and generally unwelcome, so please avoid making changes like
that.

Instead, I would consider adding a device attribute to allow user space to
opt in for getting offline notifications for specific individual devices (by
setting that attribute user space would tell the kernel that it wants to
get offline notifications for the device in question and it would take
care of offlining it as needed).



2020-03-13 08:41:21

by Chester Lin

[permalink] [raw]
Subject: Re: [RFC PATCH v2 1/3] ACPI / hotplug: Send change events for offline/online requests when eject is triggered

Hi Rafael,

On Wed, Jan 15, 2020 at 11:15:08AM +0100, Rafael J. Wysocki wrote:
> On Friday, January 3, 2020 5:40:09 AM CET Chester Lin wrote:
> > Here we change offline/online handling in device hotplug by sending change
> > events to userland as notification so that userland can have control and
> > determine when will be a good time to put them offline/online based on
> > current workload. In this approach the real offline/online opertions are
> > handed over to userland so that userland can have more time to prepare
> > before any device change actually happens.
> >
> > All child devices under the ejection target are traversed and notified
> > hierarchically based on ACPI namespace in ascending order when an eject
> > event happens.
> >
> > Signed-off-by: Chester Lin <[email protected]>
>
> So you replace the old flow with the new one and make the new one mandatory AFAICS.
>
> Thus if anyone has relied on the old flow, they now need to switch over.
>
> This is unfriendly and generally unwelcome, so please avoid making changes like
> that.
>
Thank you for the reminder.

> Instead, I would consider adding a device attribute to allow user space to
> opt in for getting offline notifications for specific individual devices (by
> setting that attribute user space would tell the kernel that it wants to
> get offline notifications for the device in question and it would take
> care of offlining it as needed).
>
Thanks for your advice. If no one is working on this device attribute [please free
feel to correct me if I'm wrong], I am willing to implement it and will send a new
RFC patch for code review.

Regards,
Chester