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]
Date:   Fri, 5 Apr 2019 12:56:54 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Oscar Salvador <osalvador@...e.de>, akpm@...ux-foundation.org,
        dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic
 restrictions for memory hotplug

On 05.04.19 12:30, Michal Hocko wrote:
> On Fri 05-04-19 10:05:09, David Hildenbrand wrote:
>> On 05.04.19 09:14, Michal Hocko wrote:
>>> On Thu 04-04-19 20:27:41, David Hildenbrand wrote:
>>>> On 04.04.19 20:01, Oscar Salvador wrote:
>>> [...]
>>>>> But I am not really convinced by MHP_SYSTEM_RAM name, and I think we should stick
>>>>> with MHP_MEMBLOCK_API because it represents __what__ is that flag about and its
>>>>> function, e.g: create memory block devices.
>>>
>>> Exactly
>>
>> Fine with me for keeping what Oscar has.
>>
>>>
>>>> This nicely aligns with the sub-section memory add support discussion.
>>>>
>>>> MHP_MEMBLOCK_API immediately implies that
>>>>
>>>> - memory is used as system ram. Memory can be onlined/offlined. Markers
>>>>   at sections indicate if the section is online/offline.
>>>
>>> No there is no implication like that. It means only that the onlined
>>> memory has a sysfs interface. Nothing more, nothing less
>>
>> As soon as there is a online/offline interface, you *can* (and user
>> space usually *will*) online that memory. Onlining/offlining is only
>> defined for memory to be added to the buddy - memory to be used as
>> "system ram". Doing it for random device memory will not work / result
>> in undefined behavior.
> 
> No, not really. We really do not care where the memory comes from. Is it
> RAM, NVDIMM, $FOO_BAR_OF_A_FUTURE_BUZZ. We only do care that the memory
> can be onlined - user triggered associated with a zone. The memory even
> doesn't have to go to the page allocator.
> 

Yes, true, I was rather meaning if the caller wants ZONE_DEVICE, memory
block devices are never an option. So "how the memory is used" not
"where memory comes from".

add_memory() vs. devm_memremap_pages().

-- 

Thanks,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ