From: Wen Congyang <wency@cn.fujitsu.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
rjw@sisk.pl, lenb@kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 0/3] acpi: Introduce prepare_remove device operation
Date: Mon, 12 Nov 2012 12:00:55 +0800 [thread overview]
Message-ID: <50A07477.2050002@cn.fujitsu.com> (raw)
In-Reply-To: <1352399371-8015-1-git-send-email-vasilis.liaskovitis@profitbricks.com>
At 11/09/2012 02:29 AM, Vasilis Liaskovitis Wrote:
> As discussed in
> https://patchwork.kernel.org/patch/1581581/
> the driver core remove function needs to always succeed. This means we need
> to know that the device can be successfully removed before acpi_bus_trim /
> acpi_bus_hot_remove_device are called. This can cause panics when OSPM-initiated
> eject (echo 1 > /sys/bus/acpi/devices/PNP/eject) of memory devices fails, since
> the ACPI core goes ahead and ejects the device regardless of whether the memory
> is still in use or not.
>
> For this reason a new acpi_device operation called prepare_remove is introduced.
> This operation should be registered for acpi devices whose removal (from kernel
> perspective) can fail. Memory devices fall in this category.
>
> acpi_bus_hot_remove_device is changed to handle removal in 2 steps:
> - preparation for removal i.e. perform part of removal that can fail outside of
> ACPI core. Should succeed for device and all its children.
> - if above step was successfull, proceed to actual ACPI removal
If we unbind the device from the driver, we still need to do preparation. But
you don't do it in your patch.
Thanks
Wen Congyang
>
> acpi_bus_trim is changed accordingly to handle preparation for removal and
> actual removal.
>
> With this patchset, only acpi memory devices use the new prepare_remove
> device operation. The actual memory removal (VM-related offline and other memory
> cleanups) is moved to prepare_remove. The old remove operation just cleans up
> the acpi structures. Directly ejecting PNP0C80 memory devices works safely. I
> haven't tested yet with an ACPI container which contains memory devices.
>
> Other ACPI devices (e.g. CPU) do not register prepare_remove callbacks, and
> their OSPM-side eject should not be affected.
>
> I am not happy with the name prepare_remove. Comments welcome. Let me know if I
> should work more in this direction (I think Yasuaki might also look into this
> and might have a simpler idea)
>
> Patches are on top of Rafael's linux-pm/linux-next
>
> Vasilis Liaskovitis (3):
> acpi: Introduce prepare_remove operation in acpi_device_ops
> acpi: Make acpi_bus_trim handle device removal preparation
> acpi_memhotplug: Add prepare_remove operation
>
> drivers/acpi/acpi_memhotplug.c | 24 +++++++++++++++++++++---
> drivers/acpi/dock.c | 2 +-
> drivers/acpi/scan.c | 32 +++++++++++++++++++++++++++++---
> drivers/pci/hotplug/acpiphp_glue.c | 4 ++--
> drivers/pci/hotplug/sgi_hotplug.c | 2 +-
> include/acpi/acpi_bus.h | 4 +++-
> 6 files changed, 57 insertions(+), 11 deletions(-)
>
next prev parent reply other threads:[~2012-11-12 4:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-08 18:29 [RFC PATCH 0/3] acpi: Introduce prepare_remove device operation Vasilis Liaskovitis
2012-11-08 18:29 ` [RFC PATCH 1/3] acpi: Introduce prepare_remove operation in acpi_device_ops Vasilis Liaskovitis
2012-11-08 18:29 ` [RFC PATCH 2/3] acpi: Make acpi_bus_trim handle device removal preparation Vasilis Liaskovitis
2012-11-08 18:29 ` [RFC PATCH 3/3] acpi_memhotplug: Add prepare_remove operation Vasilis Liaskovitis
2012-11-12 4:00 ` Wen Congyang [this message]
2012-11-12 17:20 ` [RFC PATCH 0/3] acpi: Introduce prepare_remove device operation Vasilis Liaskovitis
2012-11-14 23:12 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50A07477.2050002@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=vasilis.liaskovitis@profitbricks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).