Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp220249ybi; Thu, 30 May 2019 23:58:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZbd2ueoUHFGiwaIkg9HBr/FbMzZky6/ORiXol5R4LhIUXDRG18oa8arIOOQcJDqxMsFqe X-Received: by 2002:a17:90a:ca16:: with SMTP id x22mr7282736pjt.98.1559285928062; Thu, 30 May 2019 23:58:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559285928; cv=none; d=google.com; s=arc-20160816; b=n5tmqLJCPYT61qlSvAmirgR++LKz9RgT+Rc6hW8Hwg8D8pq7+Zr8e5iMKiLKfrg0qW JhKE1uzYhG8qCmtvLWncvEZxGJYkNKERCKEv8IqYHagHIsMLTvnuYRWyOl8KgBtO8cl0 wZcqSIhL79D6mXh3p4Pu/3k2kXrfvJDlEJic9VMT+DtWeFEVeTc9hvl4dISXeCjmjW79 UPVS8OMnG5CwZ0CfmKFEWDYjtH38L48tJzd7g6RgpjFQtlvY86jslLV+IoepAOblKnGY WXhKaZrKeeEiP7hg6LKaPw/+EZMj4ba3v7EGdQbGdjh2W/9IY1v81imTUobDz7WlCuc6 UWtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=drMvm0btS8NadOUvjKxtabRwMsL88JLc0TECHglgmxU=; b=fiFcezdlcvtgxUuA4+5HsOviUBVE6EvCCv8ME6Q4p2tp6EEOcZWh/peIVe6FqSC+02 H1vxqoEmp680Jurm+j07ptZdRUGpaY9szESfRR7d5yuwBhvlFnHSPK15uHHe4wwItkgC Kh5fm6F5HGg5Xmv6H0t976ZppBEZ9+4bA4Nub/R8w4kloMpY6o2VbmTbUP9ST8Uvw3DF xRFr8S8cm+aGjO4/FL8yXygKfO9L4fFuHpR8ITwpHsuUwNjlG1kejZMv1pgjNCuYoQSH WDFNSrf2VklgRlGHzax91Y8ghyJ9Cd2VqYvY0bj3xFHb0oKZZxKbrTMIAgyW/IJ0YoVS jljQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10si5662275pfk.222.2019.05.30.23.58.31; Thu, 30 May 2019 23:58:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726520AbfEaG53 (ORCPT + 99 others); Fri, 31 May 2019 02:57:29 -0400 Received: from smtp2.provo.novell.com ([137.65.250.81]:46203 "EHLO smtp2.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726002AbfEaG53 (ORCPT ); Fri, 31 May 2019 02:57:29 -0400 Received: from linux-8mug.suse.de (prva10-snat226-1.provo.novell.com [137.65.226.35]) by smtp2.provo.novell.com with ESMTP (TLS encrypted); Fri, 31 May 2019 00:57:24 -0600 From: Chester Lin To: rjw@rjwysocki.net, lenb@kernel.org, gregkh@linuxfoundation.org Cc: jlee@suse.com, mhocko@suse.com, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Chester Lin Subject: [PATCH 0/3] ACPI: New eject flow to remove devices cautiously Date: Fri, 31 May 2019 14:56:39 +0800 Message-Id: <20190531065642.13254-1-clin@suse.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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 attr to monitor eject status drivers/acpi/container.c | 2 +- drivers/acpi/device_sysfs.c | 20 ++- drivers/acpi/glue.c | 81 ++++++++++ drivers/acpi/internal.h | 31 +++- drivers/acpi/scan.c | 298 ++++++++++++++++++++++++++---------- drivers/base/core.c | 2 + include/acpi/acpi_bus.h | 3 +- 7 files changed, 356 insertions(+), 81 deletions(-) -- 2.20.1