linux-kernel - Re: [PATCH V3 0/3] mm/memory_hotplug: Pre-validate the address range with platform

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: <c37de2d0-28a1-4f7d-f944-cfd7d81c334d@redhat.com>
Date:   Fri, 22 Jan 2021 09:34:50 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Anshuman Khandual <anshuman.khandual@....com>,
        Oscar Salvador <osalvador@...e.de>
Cc:     linux-mm@...ck.org, akpm@...ux-foundation.org, hca@...ux.ibm.com,
        catalin.marinas@....com, Vasily Gorbik <gor@...ux.ibm.com>,
        Will Deacon <will@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 0/3] mm/memory_hotplug: Pre-validate the address range
 with platform

On 22.01.21 07:04, Anshuman Khandual wrote:
> 
> 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

As mentioned in another thread to Oscar, I already have a cleanup patch
for that one lying around, part of a bigger series. Might just send that
one out separately earlier.

> clean up patch ? Would there be a problem with memhp_default_state
> being a command line parameter ?

Yes, that one we should not change, to not break existing cmdlines
without good reason. We could change the
memhp_default_online_type/memhp_online_type_from_str/... thingies, though.

Feel free to send a patch, thanks!

-- 
Thanks,

David / dhildenb