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

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

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?

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

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?

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.

I.e. fragility of an interface is our choice, not some natural given
property.

Thanks,

Ingo


\
 
 \ /
  Last update: 2013-07-23 11:21    [W:0.165 / U:0.580 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site