On Tue, 2013-07-23 at 10:01 +0200, Ingo Molnar wrote:* Toshi Kani <toshi.kani@xxxxxx> wrote:Agreed.
Not crashing the kernel is not a novel concept even for test interfaces...Could we please also fix it to never crash the kernel, even if stupidYes, this probe interface can be enhanced to verify the firmware
ranges are provided?
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.
Where does the possible crash come from - from using invalid RAM ranges,Yes, the crash comes from using invalid RAM ranges. How to check if the
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?
RAM is present is different if the system supports hotplug or not.
Yes for boot time. At run-time, e820 is not guaranteed to represent aIn order to verify if a given memory address is enabled at run-time (asAll vendors implement e820 maps for the memory present at boot time.
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.
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 lessIf we focus on this test scenario on a system that does not support
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?
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 theIn high-level, here is how ACPI memory hotplug works:
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.
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.
Thanks,
-Toshi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>