From: Wen Congyang <wencongyang@gmail.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
wency@cn.fujitsu.com, rjw@sisk.pl, lenb@kernel.org,
toshi.kani@hp.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 2/3] acpi_memhotplug: Add prepare_remove operation
Date: Sun, 25 Nov 2012 00:23:47 +0800 [thread overview]
Message-ID: <50B0F493.3000103@gmail.com> (raw)
In-Reply-To: <1353693037-21704-3-git-send-email-vasilis.liaskovitis@profitbricks.com>
At 2012/11/24 1:50, Vasilis Liaskovitis Wrote:
> Offlining and removal of memory is now done in the prepare_remove callback,
> not in the remove callback.
>
> The prepare_remove callback will be called when trying to remove a memory device
> with the following ways:
>
> 1. send eject request by SCI
> 2. echo 1>/sys/bus/pci/devices/PNP0C80:XX/eject
>
> Note that unbinding the acpi driver from a memory device with:
> echo "PNP0C80:XX"> /sys/bus/acpi/drivers/acpi_memhotplug/unbind
>
> will no longer try to remove the memory. This is in compliance with normal
> unbind driver core semantics, see the discussion in v2 of this patchset:
> https://lkml.org/lkml/2012/11/16/649
If we don't remove it when unbinding it, it may cause kernel panicked.
I have explained in another mail.
Thanks
Wen Congyang
>
> After a successful unbind of the driver:
> - OSPM ejects of the memory device cannot proceed, as acpi_eject_store will
> return -ENODEV on missing driver.
> - SCI ejects of the memory device also cannot proceed, as they will also get
> a "driver data is NULL" error.
> So the memory can continue to be used safely after unbind.
>
> Signed-off-by: Vasilis Liaskovitis<vasilis.liaskovitis@profitbricks.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 18 ++++++++++++++++--
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index eb30e5a..d0cfbd9 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -55,6 +55,7 @@ MODULE_LICENSE("GPL");
>
> static int acpi_memory_device_add(struct acpi_device *device);
> static int acpi_memory_device_remove(struct acpi_device *device, int type);
> +static int acpi_memory_device_prepare_remove(struct acpi_device *device);
>
> static const struct acpi_device_id memory_device_ids[] = {
> {ACPI_MEMORY_DEVICE_HID, 0},
> @@ -69,6 +70,7 @@ static struct acpi_driver acpi_memory_device_driver = {
> .ops = {
> .add = acpi_memory_device_add,
> .remove = acpi_memory_device_remove,
> + .prepare_remove = acpi_memory_device_prepare_remove,
> },
> };
>
> @@ -448,6 +450,20 @@ static int acpi_memory_device_add(struct acpi_device *device)
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> +
> + if (!device || !acpi_driver_data(device))
> + return -EINVAL;
> +
> + mem_device = acpi_driver_data(device);
> +
> + acpi_memory_device_free(mem_device);
> +
> + return 0;
> +}
> +
> +static int acpi_memory_device_prepare_remove(struct acpi_device *device)
> +{
> + struct acpi_memory_device *mem_device = NULL;
> int result;
>
> if (!device || !acpi_driver_data(device))
> @@ -459,8 +475,6 @@ static int acpi_memory_device_remove(struct acpi_device *device, int type)
> if (result)
> return result;
>
> - acpi_memory_device_free(mem_device);
> -
> return 0;
> }
>
WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wencongyang@gmail.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
wency@cn.fujitsu.com, rjw@sisk.pl, lenb@kernel.org,
toshi.kani@hp.com, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 2/3] acpi_memhotplug: Add prepare_remove operation
Date: Sun, 25 Nov 2012 00:23:47 +0800 [thread overview]
Message-ID: <50B0F493.3000103@gmail.com> (raw)
In-Reply-To: <1353693037-21704-3-git-send-email-vasilis.liaskovitis@profitbricks.com>
At 2012/11/24 1:50, Vasilis Liaskovitis Wrote:
> Offlining and removal of memory is now done in the prepare_remove callback,
> not in the remove callback.
>
> The prepare_remove callback will be called when trying to remove a memory device
> with the following ways:
>
> 1. send eject request by SCI
> 2. echo 1>/sys/bus/pci/devices/PNP0C80:XX/eject
>
> Note that unbinding the acpi driver from a memory device with:
> echo "PNP0C80:XX"> /sys/bus/acpi/drivers/acpi_memhotplug/unbind
>
> will no longer try to remove the memory. This is in compliance with normal
> unbind driver core semantics, see the discussion in v2 of this patchset:
> https://lkml.org/lkml/2012/11/16/649
If we don't remove it when unbinding it, it may cause kernel panicked.
I have explained in another mail.
Thanks
Wen Congyang
>
> After a successful unbind of the driver:
> - OSPM ejects of the memory device cannot proceed, as acpi_eject_store will
> return -ENODEV on missing driver.
> - SCI ejects of the memory device also cannot proceed, as they will also get
> a "driver data is NULL" error.
> So the memory can continue to be used safely after unbind.
>
> Signed-off-by: Vasilis Liaskovitis<vasilis.liaskovitis@profitbricks.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 18 ++++++++++++++++--
> 1 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index eb30e5a..d0cfbd9 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -55,6 +55,7 @@ MODULE_LICENSE("GPL");
>
> static int acpi_memory_device_add(struct acpi_device *device);
> static int acpi_memory_device_remove(struct acpi_device *device, int type);
> +static int acpi_memory_device_prepare_remove(struct acpi_device *device);
>
> static const struct acpi_device_id memory_device_ids[] = {
> {ACPI_MEMORY_DEVICE_HID, 0},
> @@ -69,6 +70,7 @@ static struct acpi_driver acpi_memory_device_driver = {
> .ops = {
> .add = acpi_memory_device_add,
> .remove = acpi_memory_device_remove,
> + .prepare_remove = acpi_memory_device_prepare_remove,
> },
> };
>
> @@ -448,6 +450,20 @@ static int acpi_memory_device_add(struct acpi_device *device)
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> +
> + if (!device || !acpi_driver_data(device))
> + return -EINVAL;
> +
> + mem_device = acpi_driver_data(device);
> +
> + acpi_memory_device_free(mem_device);
> +
> + return 0;
> +}
> +
> +static int acpi_memory_device_prepare_remove(struct acpi_device *device)
> +{
> + struct acpi_memory_device *mem_device = NULL;
> int result;
>
> if (!device || !acpi_driver_data(device))
> @@ -459,8 +475,6 @@ static int acpi_memory_device_remove(struct acpi_device *device, int type)
> if (result)
> return result;
>
> - acpi_memory_device_free(mem_device);
> -
> return 0;
> }
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-11-24 16:23 UTC|newest]
Thread overview: 191+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-23 17:50 [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation Vasilis Liaskovitis
2012-11-23 17:50 ` Vasilis Liaskovitis
2012-11-23 17:50 ` [RFC PATCH v3 1/3] acpi: Introduce prepare_remove operation in acpi_device_ops Vasilis Liaskovitis
2012-11-23 17:50 ` Vasilis Liaskovitis
2012-11-27 0:10 ` Toshi Kani
2012-11-27 0:10 ` Toshi Kani
2012-11-27 18:36 ` Vasilis Liaskovitis
2012-11-27 18:36 ` Vasilis Liaskovitis
2012-11-27 23:18 ` Rafael J. Wysocki
2012-11-27 23:18 ` Rafael J. Wysocki
2012-11-23 17:50 ` [RFC PATCH v3 2/3] acpi_memhotplug: Add prepare_remove operation Vasilis Liaskovitis
2012-11-23 17:50 ` Vasilis Liaskovitis
2012-11-24 16:23 ` Wen Congyang [this message]
2012-11-24 16:23 ` Wen Congyang
2012-11-23 17:50 ` [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario Vasilis Liaskovitis
2012-11-23 17:50 ` Vasilis Liaskovitis
2012-11-24 16:20 ` Wen Congyang
2012-11-24 16:20 ` Wen Congyang
2012-11-26 8:36 ` Vasilis Liaskovitis
2012-11-26 8:36 ` Vasilis Liaskovitis
2012-11-26 9:11 ` Wen Congyang
2012-11-26 9:11 ` Wen Congyang
2012-11-27 0:19 ` Toshi Kani
2012-11-27 0:19 ` Toshi Kani
2012-11-27 18:32 ` Vasilis Liaskovitis
2012-11-27 18:32 ` Vasilis Liaskovitis
2012-11-27 22:03 ` Toshi Kani
2012-11-27 22:03 ` Toshi Kani
2012-11-27 23:41 ` Rafael J. Wysocki
2012-11-27 23:41 ` Rafael J. Wysocki
2012-11-28 16:01 ` Toshi Kani
2012-11-28 16:01 ` Toshi Kani
2012-11-28 18:40 ` Rafael J. Wysocki
2012-11-28 18:40 ` Rafael J. Wysocki
2012-11-28 21:02 ` Toshi Kani
2012-11-28 21:02 ` Toshi Kani
2012-11-28 21:40 ` Rafael J. Wysocki
2012-11-28 21:40 ` Rafael J. Wysocki
2012-11-28 21:40 ` Toshi Kani
2012-11-28 21:40 ` Toshi Kani
2012-11-28 22:01 ` Rafael J. Wysocki
2012-11-28 22:01 ` Rafael J. Wysocki
2012-11-28 22:04 ` Toshi Kani
2012-11-28 22:04 ` Toshi Kani
2012-11-28 22:21 ` Rafael J. Wysocki
2012-11-28 22:21 ` Rafael J. Wysocki
2012-11-28 22:16 ` Toshi Kani
2012-11-28 22:16 ` Toshi Kani
2012-11-28 22:39 ` Rafael J. Wysocki
2012-11-28 22:39 ` Rafael J. Wysocki
2012-11-28 22:46 ` Greg KH
2012-11-28 22:46 ` Greg KH
2012-11-28 23:05 ` Rafael J. Wysocki
2012-11-28 23:05 ` Rafael J. Wysocki
2012-11-28 23:10 ` Greg KH
2012-11-28 23:10 ` Greg KH
2012-11-28 23:31 ` Rafael J. Wysocki
2012-11-28 23:31 ` Rafael J. Wysocki
2012-11-28 23:49 ` Rafael J. Wysocki
2012-11-28 23:49 ` Rafael J. Wysocki
2012-11-29 1:02 ` Toshi Kani
2012-11-29 1:02 ` Toshi Kani
2012-11-29 1:15 ` Toshi Kani
2012-11-29 1:15 ` Toshi Kani
2012-11-29 10:03 ` Rafael J. Wysocki
2012-11-29 10:03 ` Rafael J. Wysocki
2012-11-29 11:30 ` Vasilis Liaskovitis
2012-11-29 11:30 ` Vasilis Liaskovitis
2012-11-29 16:57 ` Rafael J. Wysocki
2012-11-29 16:57 ` Rafael J. Wysocki
2012-11-29 17:56 ` Toshi Kani
2012-11-29 17:56 ` Toshi Kani
2012-11-29 20:25 ` Rafael J. Wysocki
2012-11-29 20:25 ` Rafael J. Wysocki
2012-11-29 20:38 ` Toshi Kani
2012-11-29 20:38 ` Toshi Kani
2012-11-29 21:23 ` Rafael J. Wysocki
2012-11-29 21:23 ` Rafael J. Wysocki
2012-11-29 21:46 ` Toshi Kani
2012-11-29 21:46 ` Toshi Kani
2012-11-29 22:11 ` Rafael J. Wysocki
2012-11-29 22:11 ` Rafael J. Wysocki
2012-11-29 23:17 ` Toshi Kani
2012-11-29 23:17 ` Toshi Kani
2012-11-30 0:13 ` Rafael J. Wysocki
2012-11-30 0:13 ` Rafael J. Wysocki
2012-11-30 1:09 ` Toshi Kani
2012-11-30 1:09 ` Toshi Kani
2012-11-29 16:43 ` Toshi Kani
2012-11-29 16:43 ` Toshi Kani
2012-11-29 11:04 ` Vasilis Liaskovitis
2012-11-29 11:04 ` Vasilis Liaskovitis
2012-11-29 17:44 ` Toshi Kani
2012-11-29 17:44 ` Toshi Kani
2012-12-06 9:30 ` Vasilis Liaskovitis
2012-12-06 9:30 ` Vasilis Liaskovitis
2012-12-06 12:50 ` Rafael J. Wysocki
2012-12-06 12:50 ` Rafael J. Wysocki
2012-12-06 15:41 ` Toshi Kani
2012-12-06 15:41 ` Toshi Kani
2012-12-06 20:32 ` Rafael J. Wysocki
2012-12-06 20:32 ` Rafael J. Wysocki
2012-11-28 11:05 ` [RFC PATCH v3 0/3] acpi: Introduce prepare_remove device operation Hanjun Guo
2012-11-28 11:05 ` Hanjun Guo
2012-11-28 11:05 ` Hanjun Guo
2012-11-28 18:41 ` Toshi Kani
2012-11-28 18:41 ` Toshi Kani
2012-11-29 4:48 ` Hanjun Guo
2012-11-29 4:48 ` Hanjun Guo
2012-11-29 4:48 ` Hanjun Guo
2012-11-29 22:27 ` Toshi Kani
2012-11-29 22:27 ` Toshi Kani
2012-12-03 4:25 ` Hanjun Guo
2012-12-03 4:25 ` Hanjun Guo
2012-12-03 4:25 ` Hanjun Guo
2012-12-04 0:10 ` Toshi Kani
2012-12-04 0:10 ` Toshi Kani
2012-12-04 9:16 ` Hanjun Guo
2012-12-04 9:16 ` Hanjun Guo
2012-12-04 9:16 ` Hanjun Guo
2012-12-04 23:23 ` Toshi Kani
2012-12-04 23:23 ` Toshi Kani
2012-12-05 12:10 ` Hanjun Guo
2012-12-05 12:10 ` Hanjun Guo
2012-12-05 12:10 ` Hanjun Guo
2012-12-05 22:31 ` Toshi Kani
2012-12-05 22:31 ` Toshi Kani
2012-12-06 16:47 ` Jiang Liu
2012-12-06 16:47 ` Jiang Liu
2012-12-07 2:25 ` Toshi Kani
2012-12-07 2:25 ` Toshi Kani
2012-12-06 16:40 ` Jiang Liu
2012-12-06 16:40 ` Jiang Liu
2012-12-06 16:40 ` Jiang Liu
2012-12-06 20:30 ` Rafael J. Wysocki
2012-12-06 20:30 ` Rafael J. Wysocki
2012-12-07 2:57 ` Toshi Kani
2012-12-07 2:57 ` Toshi Kani
2012-12-07 5:57 ` Jiang Liu
2012-12-07 5:57 ` Jiang Liu
2012-12-07 5:57 ` Jiang Liu
2012-12-08 1:08 ` Toshi Kani
2012-12-08 1:08 ` Toshi Kani
2012-12-11 14:34 ` Jiang Liu
2012-12-11 14:34 ` Jiang Liu
2012-12-13 14:42 ` Toshi Kani
2012-12-13 14:42 ` Toshi Kani
2012-12-13 15:15 ` Jiang Liu
2012-12-13 15:15 ` Jiang Liu
2012-12-15 1:19 ` Toshi Kani
2012-12-15 1:19 ` Toshi Kani
2012-11-29 10:15 ` Rafael J. Wysocki
2012-11-29 10:15 ` Rafael J. Wysocki
2012-11-29 11:36 ` Vasilis Liaskovitis
2012-11-29 11:36 ` Vasilis Liaskovitis
2012-12-06 16:59 ` Jiang Liu
2012-12-06 16:59 ` Jiang Liu
2012-11-29 17:03 ` Toshi Kani
2012-11-29 17:03 ` Toshi Kani
2012-11-29 20:30 ` Rafael J. Wysocki
2012-11-29 20:30 ` Rafael J. Wysocki
2012-11-29 20:39 ` Toshi Kani
2012-11-29 20:39 ` Toshi Kani
2012-11-29 20:56 ` Toshi Kani
2012-11-29 20:56 ` Toshi Kani
2012-11-29 21:25 ` Rafael J. Wysocki
2012-11-29 21:25 ` Rafael J. Wysocki
2012-12-06 17:10 ` Jiang Liu
2012-12-06 17:10 ` Jiang Liu
2012-12-06 17:07 ` Jiang Liu
2012-12-06 17:07 ` Jiang Liu
2012-12-06 17:01 ` Jiang Liu
2012-12-06 17:01 ` Jiang Liu
2012-12-06 16:56 ` Jiang Liu
2012-12-06 16:56 ` Jiang Liu
2012-12-06 16:00 ` Jiang Liu
2012-12-06 16:00 ` Jiang Liu
2012-12-06 16:03 ` Toshi Kani
2012-12-06 16:03 ` Toshi Kani
2012-12-06 16:25 ` Jiang Liu
2012-12-06 16:25 ` Jiang Liu
2012-12-06 16:31 ` Toshi Kani
2012-12-06 16:31 ` Toshi Kani
2012-12-06 16:52 ` Jiang Liu
2012-12-06 16:52 ` Jiang Liu
2012-12-06 17:09 ` Toshi Kani
2012-12-06 17:09 ` Toshi Kani
2012-12-06 17:30 ` Jiang Liu
2012-12-06 17:30 ` Jiang Liu
2012-12-06 17:28 ` Toshi Kani
2012-12-06 17:28 ` Toshi Kani
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=50B0F493.3000103@gmail.com \
--to=wencongyang@gmail.com \
--cc=gregkh@linuxfoundation.org \
--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=rjw@sisk.pl \
--cc=toshi.kani@hp.com \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wency@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.