All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, cl@linux.com,
	minchan.kim@gmail.com, akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
Date: Mon, 08 Oct 2012 14:58:12 +0800	[thread overview]
Message-ID: <50727984.20401@cn.fujitsu.com> (raw)
In-Reply-To: <CAHGf_=p7PaQs-kpnyB8uC1MntHQfL-CXhhq4QQP54mYiqOswqQ@mail.gmail.com>

At 10/05/2012 04:53 AM, KOSAKI Motohiro Wrote:
> On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch implements acpi_memory_remove_memory() for offlining
>> memory and releasing acpi_memory_info struct. And it is used by both
>> acpi_memory_device_remove() and acpi_memory_disable_device().
>>
>> Additionally, if the type is ACPI_BUS_REMOVAL_EJECT in
>> acpi_memory_device_remove() , it means that the user wants to eject
>> the memory device. In this case, acpi_memory_device_remove() calls
>> acpi_memory_remove_memory().
>>
>> CC: David Rientjes <rientjes@google.com>
>> CC: Jiang Liu <liuj97@gmail.com>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>>  drivers/acpi/acpi_memhotplug.c |   44 +++++++++++++++++++++++++++++++----------
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> Index: linux-3.6/drivers/acpi/acpi_memhotplug.c
>> ===================================================================
>> --- linux-3.6.orig/drivers/acpi/acpi_memhotplug.c       2012-10-03 18:55:33.386378909 +0900
>> +++ linux-3.6/drivers/acpi/acpi_memhotplug.c    2012-10-03 18:55:58.624380688 +0900
>> @@ -306,24 +306,37 @@ static int acpi_memory_powerdown_device(
>>         return 0;
>>  }
>>
>> -static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
>> +static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
>>  {
>>         int result;
>>         struct acpi_memory_info *info, *n;
>>
>> +       list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
> 
> Which lock protect this loop?

There is no any lock to protect it now...

> 
> 
>> +               if (!info->enabled)
>> +                       return -EBUSY;
>> +
>> +               result = remove_memory(info->start_addr, info->length);
>> +               if (result)
>> +                       return result;
> 
> I suspect you need to implement rollback code instead of just return.
> 
> 
>> +
>> +               list_del(&info->list);
>> +               kfree(info);
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
>> +{
>> +       int result;
>>
>>         /*
>>          * Ask the VM to offline this memory range.
>>          * Note: Assume that this function returns zero on success
>>          */
> 
> Write function comment instead of this silly comment.
> 
>> -       list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>> -               if (info->enabled) {
>> -                       result = remove_memory(info->start_addr, info->length);
>> -                       if (result)
>> -                               return result;
>> -               }
>> -               kfree(info);
>> -       }
>> +       result = acpi_memory_remove_memory(mem_device);
>> +       if (result)
>> +               return result;
>>
>>         /* Power-off and eject the device */
>>         result = acpi_memory_powerdown_device(mem_device);
> 
> This patch move acpi_memory_powerdown_device() from ACPI_NOTIFY_EJECT_REQUEST
> to release callback, but don't explain why.

Hmm, it doesn't move the code. It just reuse the code in acpi_memory_powerdown_device().

> 
> 
> 
> 
> 
>> @@ -473,12 +486,23 @@ static int acpi_memory_device_add(struct
>>  static int acpi_memory_device_remove(struct acpi_device *device, int type)
>>  {
>>         struct acpi_memory_device *mem_device = NULL;
>> -
>> +       int result;
>>
>>         if (!device || !acpi_driver_data(device))
>>                 return -EINVAL;
>>
>>         mem_device = acpi_driver_data(device);
>> +
>> +       if (type == ACPI_BUS_REMOVAL_EJECT) {
>> +               /*
>> +                * offline and remove memory only when the memory device is
>> +                * ejected.
>> +                */
> 
> This comment explain nothing. A comment should describe _why_ should we do.
> e.g. Why REMOVAL_NORMAL and REMOVEL_EJECT should be ignored. Why
> we need remove memory here instead of ACPI_NOTIFY_EJECT_REQUEST.

Hmm, we have 2 ways to remove a memory:
1. SCI
2. echo 1 >/sys/bus/acpi/devices/PNP0C80:XX/eject

In the 2nd case, there is no ACPI_NOTIFY_EJECT_REQUEST. We should offline
the memory and remove it from kernel in the release callback. We will poweroff
the memory device in acpi_bus_hot_remove_device(), so we must offline
and remove it if the type is ACPI_BUS_REMOVAL_EJECT.

I guess we should not poweroff the memory device when we fail to offline it.
But device_release_driver() doesn't returns any error...

Thanks
Wen Congyang

> 
> 
>> +               result = acpi_memory_remove_memory(mem_device);
>> +               if (result)
>> +                       return result;
>> +       }
>> +
>>         kfree(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>
> 


WARNING: multiple messages have this Message-ID (diff)
From: Wen Congyang <wency@cn.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, rientjes@google.com,
	liuj97@gmail.com, len.brown@intel.com, cl@linux.com,
	minchan.kim@gmail.com, akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove()
Date: Mon, 08 Oct 2012 14:58:12 +0800	[thread overview]
Message-ID: <50727984.20401@cn.fujitsu.com> (raw)
In-Reply-To: <CAHGf_=p7PaQs-kpnyB8uC1MntHQfL-CXhhq4QQP54mYiqOswqQ@mail.gmail.com>

At 10/05/2012 04:53 AM, KOSAKI Motohiro Wrote:
> On Wed, Oct 3, 2012 at 5:58 AM, Yasuaki Ishimatsu
> <isimatu.yasuaki@jp.fujitsu.com> wrote:
>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> The memory device can be removed by 2 ways:
>> 1. send eject request by SCI
>> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>>
>> In the 1st case, acpi_memory_disable_device() will be called.
>> In the 2nd case, acpi_memory_device_remove() will be called.
>> acpi_memory_device_remove() will also be called when we unbind the
>> memory device from the driver acpi_memhotplug.
>>
>> acpi_memory_disable_device() has already implemented a code which
>> offlines memory and releases acpi_memory_info struct . But
>> acpi_memory_device_remove() has not implemented it yet.
>>
>> So the patch implements acpi_memory_remove_memory() for offlining
>> memory and releasing acpi_memory_info struct. And it is used by both
>> acpi_memory_device_remove() and acpi_memory_disable_device().
>>
>> Additionally, if the type is ACPI_BUS_REMOVAL_EJECT in
>> acpi_memory_device_remove() , it means that the user wants to eject
>> the memory device. In this case, acpi_memory_device_remove() calls
>> acpi_memory_remove_memory().
>>
>> CC: David Rientjes <rientjes@google.com>
>> CC: Jiang Liu <liuj97@gmail.com>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>>  drivers/acpi/acpi_memhotplug.c |   44 +++++++++++++++++++++++++++++++----------
>>  1 file changed, 34 insertions(+), 10 deletions(-)
>>
>> Index: linux-3.6/drivers/acpi/acpi_memhotplug.c
>> ===================================================================
>> --- linux-3.6.orig/drivers/acpi/acpi_memhotplug.c       2012-10-03 18:55:33.386378909 +0900
>> +++ linux-3.6/drivers/acpi/acpi_memhotplug.c    2012-10-03 18:55:58.624380688 +0900
>> @@ -306,24 +306,37 @@ static int acpi_memory_powerdown_device(
>>         return 0;
>>  }
>>
>> -static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
>> +static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
>>  {
>>         int result;
>>         struct acpi_memory_info *info, *n;
>>
>> +       list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
> 
> Which lock protect this loop?

There is no any lock to protect it now...

> 
> 
>> +               if (!info->enabled)
>> +                       return -EBUSY;
>> +
>> +               result = remove_memory(info->start_addr, info->length);
>> +               if (result)
>> +                       return result;
> 
> I suspect you need to implement rollback code instead of just return.
> 
> 
>> +
>> +               list_del(&info->list);
>> +               kfree(info);
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
>> +{
>> +       int result;
>>
>>         /*
>>          * Ask the VM to offline this memory range.
>>          * Note: Assume that this function returns zero on success
>>          */
> 
> Write function comment instead of this silly comment.
> 
>> -       list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>> -               if (info->enabled) {
>> -                       result = remove_memory(info->start_addr, info->length);
>> -                       if (result)
>> -                               return result;
>> -               }
>> -               kfree(info);
>> -       }
>> +       result = acpi_memory_remove_memory(mem_device);
>> +       if (result)
>> +               return result;
>>
>>         /* Power-off and eject the device */
>>         result = acpi_memory_powerdown_device(mem_device);
> 
> This patch move acpi_memory_powerdown_device() from ACPI_NOTIFY_EJECT_REQUEST
> to release callback, but don't explain why.

Hmm, it doesn't move the code. It just reuse the code in acpi_memory_powerdown_device().

> 
> 
> 
> 
> 
>> @@ -473,12 +486,23 @@ static int acpi_memory_device_add(struct
>>  static int acpi_memory_device_remove(struct acpi_device *device, int type)
>>  {
>>         struct acpi_memory_device *mem_device = NULL;
>> -
>> +       int result;
>>
>>         if (!device || !acpi_driver_data(device))
>>                 return -EINVAL;
>>
>>         mem_device = acpi_driver_data(device);
>> +
>> +       if (type == ACPI_BUS_REMOVAL_EJECT) {
>> +               /*
>> +                * offline and remove memory only when the memory device is
>> +                * ejected.
>> +                */
> 
> This comment explain nothing. A comment should describe _why_ should we do.
> e.g. Why REMOVAL_NORMAL and REMOVEL_EJECT should be ignored. Why
> we need remove memory here instead of ACPI_NOTIFY_EJECT_REQUEST.

Hmm, we have 2 ways to remove a memory:
1. SCI
2. echo 1 >/sys/bus/acpi/devices/PNP0C80:XX/eject

In the 2nd case, there is no ACPI_NOTIFY_EJECT_REQUEST. We should offline
the memory and remove it from kernel in the release callback. We will poweroff
the memory device in acpi_bus_hot_remove_device(), so we must offline
and remove it if the type is ACPI_BUS_REMOVAL_EJECT.

I guess we should not poweroff the memory device when we fail to offline it.
But device_release_driver() doesn't returns any error...

Thanks
Wen Congyang

> 
> 
>> +               result = acpi_memory_remove_memory(mem_device);
>> +               if (result)
>> +                       return result;
>> +       }
>> +
>>         kfree(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>
> 

--
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>

  reply	other threads:[~2012-10-08  6:53 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03  9:52 [PATCH 0/4] acpi,memory-hotplug : implement framework for hot removing memory Yasuaki Ishimatsu
2012-10-03  9:52 ` Yasuaki Ishimatsu
2012-10-03  9:52 ` Yasuaki Ishimatsu
2012-10-03  9:58 ` [PATCH 1/4] acpi,memory-hotplug : add memory offline code to acpi_memory_device_remove() Yasuaki Ishimatsu
2012-10-03  9:58   ` Yasuaki Ishimatsu
2012-10-04 20:53   ` KOSAKI Motohiro
2012-10-04 20:53     ` KOSAKI Motohiro
2012-10-08  6:58     ` Wen Congyang [this message]
2012-10-08  6:58       ` Wen Congyang
2012-10-12 19:10       ` KOSAKI Motohiro
2012-10-12 19:10         ` KOSAKI Motohiro
2012-10-17  6:48         ` Wen Congyang
2012-10-17  6:48           ` Wen Congyang
2012-10-17  8:59           ` KOSAKI Motohiro
2012-10-17  8:59             ` KOSAKI Motohiro
2012-10-17  9:08             ` Wen Congyang
2012-10-17  9:08               ` Wen Congyang
2012-10-17  9:18               ` KOSAKI Motohiro
2012-10-17  9:18                 ` KOSAKI Motohiro
2012-10-17  9:52                 ` Wen Congyang
2012-10-17  9:52                   ` Wen Congyang
2012-10-18  1:25                   ` Yasuaki Ishimatsu
2012-10-18  1:25                     ` Yasuaki Ishimatsu
2012-10-18  1:25                     ` Yasuaki Ishimatsu
2012-10-19  7:35                     ` Wen Congyang
2012-10-19  7:35                       ` Wen Congyang
2012-10-17  9:18         ` Wen Congyang
2012-10-17  9:18           ` Wen Congyang
2012-10-18 19:44           ` KOSAKI Motohiro
2012-10-18 19:44             ` KOSAKI Motohiro
2012-10-19  9:08             ` Wen Congyang
2012-10-19  9:08               ` Wen Congyang
2012-10-19 18:19               ` KOSAKI Motohiro
2012-10-19 18:19                 ` KOSAKI Motohiro
2012-10-20  5:02                 ` Wen Congyang
2012-10-20  5:02                   ` Wen Congyang
2012-10-22 15:11                   ` KOSAKI Motohiro
2012-10-22 15:11                     ` KOSAKI Motohiro
2012-10-22 15:34                     ` KOSAKI Motohiro
2012-10-22 15:34                       ` KOSAKI Motohiro
2012-10-03 10:02 ` [PATCH 2/4] acpi,memory-hotplug : rename remove_memory() to offline_memory() Yasuaki Ishimatsu
2012-10-03 10:02   ` Yasuaki Ishimatsu
2012-10-04 21:31   ` KOSAKI Motohiro
2012-10-04 21:31     ` KOSAKI Motohiro
2012-10-08  6:45     ` Wen Congyang
2012-10-08  6:45       ` Wen Congyang
2012-10-12 18:57       ` KOSAKI Motohiro
2012-10-12 18:57         ` KOSAKI Motohiro
2012-10-03 10:09 ` [PATCH 3/6] acpi,memory-hotplug : add physical memory hotplug code to acpi_memhotplug.c Yasuaki Ishimatsu
2012-10-03 10:09   ` Yasuaki Ishimatsu
2012-10-05 18:54   ` KOSAKI Motohiro
2012-10-05 18:54     ` KOSAKI Motohiro
2012-10-03 10:11 ` [PATCH 4/4] acpi,memory-hotplug : store the node id in acpi_memory_device Yasuaki Ishimatsu
2012-10-03 10:11   ` Yasuaki Ishimatsu
2012-10-03 10:11   ` Yasuaki Ishimatsu
2012-10-05 18:56   ` KOSAKI Motohiro
2012-10-05 18:56     ` KOSAKI Motohiro
2012-10-08  6:47     ` Wen Congyang
2012-10-08  6:47       ` Wen Congyang
2012-10-12 18:59       ` KOSAKI Motohiro
2012-10-12 18:59         ` KOSAKI Motohiro
2012-10-06 14:22 ` [PATCH 0/4] acpi,memory-hotplug : implement framework for hot removing memory Ni zhan Chen
2012-10-06 14:22   ` Ni zhan Chen

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=50727984.20401@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuj97@gmail.com \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    --cc=x86@kernel.org \
    /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.