From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77407C433E0 for ; Fri, 22 Jan 2021 06:04:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E707E238D7 for ; Fri, 22 Jan 2021 06:04:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E707E238D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DD88A6B0006; Fri, 22 Jan 2021 01:04:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D60F96B0007; Fri, 22 Jan 2021 01:04:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C284D6B0008; Fri, 22 Jan 2021 01:04:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id A9F496B0006 for ; Fri, 22 Jan 2021 01:04:06 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6AF735823 for ; Fri, 22 Jan 2021 06:04:06 +0000 (UTC) X-FDA: 77732370492.30.stone05_150d4e427569 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 46AA3180B3AB8 for ; Fri, 22 Jan 2021 06:04:06 +0000 (UTC) X-HE-Tag: stone05_150d4e427569 X-Filterd-Recvd-Size: 4000 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Fri, 22 Jan 2021 06:04:05 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BFDF211B3; Thu, 21 Jan 2021 22:04:04 -0800 (PST) Received: from [10.163.92.92] (unknown [10.163.92.92]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B7D03F68F; Thu, 21 Jan 2021 22:04:00 -0800 (PST) Subject: Re: [PATCH V3 0/3] mm/memory_hotplug: Pre-validate the address range with platform From: Anshuman Khandual To: Oscar Salvador , David Hildenbrand Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hca@linux.ibm.com, catalin.marinas@arm.com, Vasily Gorbik , Will Deacon , Ard Biesheuvel , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org References: <1610975582-12646-1-git-send-email-anshuman.khandual@arm.com> <20210119134016.GA23408@linux> <8df4e1e1-1ddd-398e-c9a6-17a67d8a95bc@arm.com> Message-ID: <1c8c204d-1f96-d3aa-1b7b-ec4cc7b1b79b@arm.com> Date: Fri, 22 Jan 2021 11:34:24 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8df4e1e1-1ddd-398e-c9a6-17a67d8a95bc@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 1/20/21 2:07 PM, Anshuman Khandual wrote: > > > On 1/19/21 7:10 PM, Oscar Salvador wrote: >> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote: >>> Minor thing, we should make up our mind if we want to call stuff >>> internally "memhp_" or "mhp". I prefer the latter, because it is shorter. >> >> I would rather use the latter as well. I used that in [1]. > > Okay, will change all that is 'memhp' as 'mhp' instead. > >> MEMHP_MERGE_RESOURCE should be renamed if we agree on that. >> >> [1] https://patchwork.kernel.org/project/linux-mm/cover/20201217130758.11565-1-osalvador@suse.de/ >> While replacing 'memhp' as 'mhp' in this series, noticed there are some more 'memhp' scattered around the code from earlier. A mix of both 'memhp' and 'mhp' might not be a good idea. Hence should we just change these remaining 'memhp' as 'mhp' as well and possibly also MEMHP_MERGE_RESOURCE as suggested earlier, in a subsequent clean up patch ? Would there be a problem with memhp_default_state being a command line parameter ? >From a tree wide search - Documentation/admin-guide/kernel-parameters.txt: memhp_default_state=online/offline drivers/base/memory.c:int memhp_online_type_from_str(const char *str) drivers/base/memory.c: const int online_type = memhp_online_type_from_str(buf); drivers/base/memory.c: online_type_to_str[memhp_default_online_type]); drivers/base/memory.c: const int online_type = memhp_online_type_from_str(buf); drivers/base/memory.c: memhp_default_online_type = online_type; include/linux/memory_hotplug.h:extern int memhp_online_type_from_str(const char *str); include/linux/memory_hotplug.h:extern int memhp_default_online_type; mm/memory_hotplug.c:int memhp_default_online_type = MMOP_OFFLINE; mm/memory_hotplug.c:int memhp_default_online_type = MMOP_ONLINE; mm/memory_hotplug.c:static int __init setup_memhp_default_state(char *str) mm/memory_hotplug.c: const int online_type = memhp_online_type_from_str(str); mm/memory_hotplug.c: memhp_default_online_type = online_type; mm/memory_hotplug.c:__setup("memhp_default_state=", setup_memhp_default_state); mm/memory_hotplug.c: mem->online_type = memhp_default_online_type; mm/memory_hotplug.c: if (memhp_default_online_type != MMOP_OFFLINE)