linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, x86@kernel.org, dave@sr71.net,
	kosaki.motohiro@gmail.com, isimatu.yasuaki@jp.fujitsu.com,
	tangchen@cn.fujitsu.com, vasilis.liaskovitis@profitbricks.com
Subject: Re: [PATCH v2] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default
Date: Mon, 22 Jul 2013 16:57:38 -0400	[thread overview]
Message-ID: <51ED9CC2.8040604@gmail.com> (raw)
In-Reply-To: <1374513120.16322.21.camel@misato.fc.hp.com>

(7/22/13 1:12 PM), Toshi Kani wrote:
> On Mon, 2013-07-22 at 10:37 +0200, Ingo Molnar wrote:
>> * Toshi Kani <toshi.kani@hp.com> wrote:
>>
>>> CONFIG_ARCH_MEMORY_PROBE enables /sys/devices/system/memory/probe
>>> interface, which allows a given memory address to be hot-added as
>>> follows. (See Documentation/memory-hotplug.txt for more detail.)
>>>
>>> # echo start_address_of_new_memory > /sys/devices/system/memory/probe
>>>
>>> This probe interface is required on powerpc. On x86, however, ACPI
>>> notifies a memory hotplug event to the kernel, which performs its
>>> hotplug operation as the result. Therefore, regular users do not need
>>> this interface on x86. This probe interface is also error-prone and
>>> misleading that the kernel blindly adds a given memory address without
>>> checking if the memory is present on the system; no probing is done
>>> despite of its name. The kernel crashes when a user requests to online
>>> a memory block that is not present on the system. This interface is
>>> currently used for testing as it can fake a hotplug event.
>>>
>>> This patch disables CONFIG_ARCH_MEMORY_PROBE by default on x86, adds
>>> its Kconfig menu entry on x86, and clarifies its use in Documentation/
>>> memory-hotplug.txt.
>>
>> Could we please also fix it to never crash the kernel, even if stupid
>> ranges are provided?
>
> Yes, this probe interface can be enhanced to verify the firmware
> information before adding a given memory address.  However, such change
> would interfere its test use of "fake" hotplug, which is only the known
> use-case of this interface on x86.
>
> In order to verify if a given memory address is enabled at run-time (as
> opposed to boot-time), we need to check with ACPI memory device objects
> on x86.  However, system vendors tend to not implement memory device
> objects unless their systems support memory hotplug.  Dave Hansen is
> using this interface for his testing as a way to fake a hotplug event on
> a system that does not support memory hotplug.

One of possible option is to return EINVAL when system has real hotplug device.
I mean this interface is only useful when system don't have proper hardware
feature and doesn't work correctly hardware property and this interface command
are not consistent.

Dave, What do you think?


  reply	other threads:[~2013-07-22 20:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19 17:47 [PATCH v2] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default Toshi Kani
2013-07-19 19:30 ` KOSAKI Motohiro
2013-07-19 19:35   ` Toshi Kani
2013-07-22  8:37 ` Ingo Molnar
2013-07-22 17:12   ` Toshi Kani
2013-07-22 20:57     ` KOSAKI Motohiro [this message]
2013-07-22 21:04       ` Dave Hansen
2013-07-23  0:34       ` Toshi Kani
2013-07-23  8:01     ` Ingo Molnar
2013-07-23 20:45       ` Toshi Kani
2013-07-23 20:59         ` Dave Hansen
2013-07-23 21:34           ` Toshi Kani
2013-07-24  0:18         ` Hush Bensen
2013-07-24 16:02           ` Toshi Kani
2013-07-25  0:17             ` Hush Bensen
2013-07-25 15:47               ` Toshi Kani
2013-07-25  0:44             ` Hush Bensen
2013-07-25  0:56             ` Hush Bensen
2013-07-25  3:08               ` Yasuaki Ishimatsu
2013-07-25  3:34                 ` Hush Bensen
2013-07-25  4:55                   ` Yasuaki Ishimatsu
2013-07-24  4:20         ` Ingo Molnar
2013-07-24 16:58           ` Toshi Kani
2013-07-25 21:38             ` Ingo Molnar
2013-07-25 22:36               ` Toshi Kani
2013-07-23  0:24 ` Yasuaki Ishimatsu
2013-07-23  0:45   ` Toshi Kani
2013-07-23  7:46 ` [tip:x86/mm] " tip-bot for 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=51ED9CC2.8040604@gmail.com \
    --to=kosaki.motohiro@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave@sr71.net \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@kernel.org \
    --cc=tangchen@cn.fujitsu.com \
    --cc=toshi.kani@hp.com \
    --cc=vasilis.liaskovitis@profitbricks.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 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).