lkml.org 
[lkml]   [2013]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default
On 07/24/2013 04:45 AM, Toshi Kani wrote:
> On Tue, 2013-07-23 at 10:01 +0200, Ingo Molnar wrote:
>> * Toshi Kani <toshi.kani@hp.com> wrote:
>>
>>>> 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.
>> Not crashing the kernel is not a novel concept even for test interfaces...
> Agreed.
>
>> Where does the possible crash come from - from using invalid RAM ranges,
>> right? I.e. on x86 to fix the crash we need to check the RAM is present in
>> the e820 maps, is marked RAM there, and is not already registered with the
>> kernel, or so?
> Yes, the crash comes from using invalid RAM ranges. How to check if the
> RAM is present is different if the system supports hotplug or not.

Could you explain different methods to check the RAM is present if the
system supports hotplkug or not?

>
>>> 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.
>> All vendors implement e820 maps for the memory present at boot time.
> Yes for boot time. At run-time, e820 is not guaranteed to represent a
> new memory added. Here is a quote from ACPI spec.
>
> ===
> 15.1 INT 15H, E820H - Query System Address Map
> :
> The memory map conveyed by this interface is not required to reflect any
> changes in available physical memory that have occurred after the BIOS
> has initially passed control to the operating system. For example, if
> memory is added dynamically, this interface is not required to reflect
> the new system memory configuration.
> ===
>
> By definition, the "probe" interface is used for the kernel to recognize
> a new memory added at run-time. So, it should check ACPI memory device
> objects (which represents run-time state) for the verification. On x86,
> however, ACPI also sends a hotplug event to the kernel, which triggers
> the kernel to recognize the new physical memory properly. Hence, users
> do not need this "probe" interface.
>
>> How is the testing done by Dave Hansen? If it's done by booting with less
>> RAM than available (via say the mem=1g boot parameter), and then
>> hot-adding some of the missing RAM, then this could be made safe via the
>> e820 maps and by consultig the physical memory maps (to avoid double
>> registry), right?
> If we focus on this test scenario on a system that does not support
> hotplug, yes, I agree that we can check with e820 since it is safe to
> assume that the system has no change after boot. IOW, it is unsafe to
> check with e820 if the system supports hotplug, but there is no use in
> this interface for testing if the system supports hotplug. So, this may
> be a good idea.
>
> Dave, is this how you are testing? Do you always specify a valid memory
> address for your testing?
>
>> How does the hotplug event based approach solve double adds? Relies on the
>> hardware not sending a hot-add event twice for the same memory area or for
>> an invalid memory area, or does it include fail-safes and double checks as
>> well to avoid double adds and adding invalid memory? If yes then that
>> could be utilized here as well.
> In high-level, here is how ACPI memory hotplug works:
>
> 1. ACPI sends a hotplug event to a new ACPI memory device object that is
> hot-added.
> 2. The kernel is notified, and verifies if the new memory device object
> has not been attached by any handler yet.
> 3. The memory handler is called, and obtains a new memory range from the
> ACPI memory device object.
> 4. The memory handler calls add_memory() with the new address range.
>
> The above step 1-4 proceeds automatically within the kernel. No user
> input (nor sysfs interface) is necessary. Step 2 prevents double adds
> and step 3 gets a valid address range from the firmware directly. Step
> 4 is basically the same as the "probe" interface, but with all the
> verification up front, this step is safe.

This is hot-added part, could you also explain how ACPI memory hotplug
works for hot-remove?

>
> Thanks,
> -Toshi
>
>
> --
> 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>



\
 
 \ /
  Last update: 2013-07-24 03:01    [W:0.114 / U:0.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site