linux-kernel - Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe device

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <198063b0-fcc9-7beb-7476-86ed5f04734c@arm.com>
Date:   Mon, 27 Nov 2017 15:33:01 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Andrea Reale <ar@...ux.vnet.ibm.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     mark.rutland@....com, realean2@...ibm.com, mhocko@...e.com,
        m.bielski@...tualopensystems.com, scott.branden@...adcom.com,
        catalin.marinas@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        arunks@....qualcomm.com, qiuxishi@...wei.com
Subject: Re: [PATCH v2 4/5] mm: memory_hotplug: Add memory hotremove probe
 device

On 23/11/17 11:14, Andrea Reale wrote:
> Adding a "remove" sysfs handle that can be used to trigger
> memory hotremove manually, exactly simmetrically with
> what happens with the "probe" device for hot-add.
> 
> This is usueful for architecture that do not rely on
> ACPI for memory hot-remove.

Is there a real-world use-case for this, or is it mostly just a handy 
development feature?

> Signed-off-by: Andrea Reale <ar@...ux.vnet.ibm.com>
> Signed-off-by: Maciej Bielski <m.bielski@...tualopensystems.com>
> ---
>   drivers/base/memory.c | 34 +++++++++++++++++++++++++++++++++-
>   1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 1d60b58..8ccb67c 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -530,7 +530,36 @@ memory_probe_store(struct device *dev, struct device_attribute *attr,
>   }
>   
>   static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
> -#endif
> +
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +static ssize_t
> +memory_remove_store(struct device *dev,
> +		struct device_attribute *attr, const char *buf, size_t count)
> +{
> +	u64 phys_addr;
> +	int nid, ret;
> +	unsigned long pages_per_block = PAGES_PER_SECTION * sections_per_block;
> +
> +	ret = kstrtoull(buf, 0, &phys_addr);
> +	if (ret)
> +		return ret;
> +
> +	if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
> +		return -EINVAL;
> +
> +	nid = memory_add_physaddr_to_nid(phys_addr);

This call looks a bit odd, since you're not doing a memory add. In fact, 
any memory being removed should already be fully known-about, so AFAICS 
it should be simple to get everything you need to know (including 
potentially the online status as mentioned earlier), through 'normal' 
methods, e.g. page_to_nid() or similar.

Robin.

> +	ret = lock_device_hotplug_sysfs();
> +	if (ret)
> +		return ret;
> +
> +	remove_memory(nid, phys_addr,
> +			 MIN_MEMORY_BLOCK_SIZE * sections_per_block);
> +	unlock_device_hotplug();
> +	return count;
> +}
> +static DEVICE_ATTR(remove, S_IWUSR, NULL, memory_remove_store);
> +#endif /* CONFIG_MEMORY_HOTREMOVE */
> +#endif /* CONFIG_ARCH_MEMORY_PROBE */
>   
>   #ifdef CONFIG_MEMORY_FAILURE
>   /*
> @@ -790,6 +819,9 @@ bool is_memblock_offlined(struct memory_block *mem)
>   static struct attribute *memory_root_attrs[] = {
>   #ifdef CONFIG_ARCH_MEMORY_PROBE
>   	&dev_attr_probe.attr,
> +#ifdef CONFIG_MEMORY_HOTREMOVE
> +	&dev_attr_remove.attr,
> +#endif
>   #endif
>   
>   #ifdef CONFIG_MEMORY_FAILURE
>