lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171204175040.2vgc6ccdcr5m77hm@arbab-laptop.localdomain>
Date:   Mon, 4 Dec 2017 11:50:41 -0600
From:   Reza Arbab <arbab@...ux.vnet.ibm.com>
To:     Andrea Reale <ar@...ux.vnet.ibm.com>
Cc:     zhong jiang <zhongjiang@...wei.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, m.bielski@...tualopensystems.com,
        arunks@....qualcomm.com, mark.rutland@....com,
        scott.branden@...adcom.com, will.deacon@....com,
        qiuxishi@...wei.com, catalin.marinas@....com, mhocko@...e.com,
        realean2@...ibm.com
Subject: Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe
 device

On Fri, Nov 24, 2017 at 02:29:48PM +0000, Andrea Reale wrote:
>But, at least in my understanding, the implementation is not as
>straightfoward as it looks. If I declare a memory node in the fdt, then,
>at boot, the kernel will expect that memory to actually be there to be
>used: this is not true if I want to plug my dimms only later at runtime.
>So I think that declaring the hotpluggable memory in an fdt memory
>node might not feasible without changes.

On the power arch, we do this today using "linux,usable-memory".

memory@...00000000 {
  device_type = "memory";
  reg = <0x100 0x0 0x0 0x80000000>;
  linux,usable-memory = <0x100 0x0 0x0 0x40000000>;
  :
}

The reg range defines the node, but at at boot, memblocks are only 
created for the linux,usable-memory range. The rest can be hotplugged 
later. YMMV, because this depends on your arch's implementation of 
memory_add_physaddr_to_nid().

>One idea could be to add a new property to memory nodes, to specify 
>what memory is potentially hotplugguable.

Somewhat related, there is already a "hotpluggable" property.

memory@...40000000 {
  device_type = "memory";
  reg = <0x100 0x40000000 0x0 0x40000000>;
  hotpluggable;
  :
}

This is subtly different from the earlier example. This memory IS 
present at boot. The hotpluggable property ensures that it resides in 
ZONE_MOVABLE so it can potentially be removed.

-- 
Reza Arbab

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ