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
| ||
|
Date: Fri, 10 May 2019 00:18:50 +0200 From: David Hildenbrand <david@...hat.com> To: Wei Yang <richard.weiyang@...il.com> Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org, linux-sh@...r.kernel.org, akpm@...ux-foundation.org, Dan Williams <dan.j.williams@...el.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, "mike.travis@....com" <mike.travis@....com>, Ingo Molnar <mingo@...nel.org>, Andrew Banman <andrew.banman@....com>, Oscar Salvador <osalvador@...e.de>, Michal Hocko <mhocko@...e.com>, Pavel Tatashin <pasha.tatashin@...een.com>, Qian Cai <cai@....pw>, Arun KS <arunks@...eaurora.org>, Mathieu Malaterre <malat@...ian.org> Subject: Re: [PATCH v2 4/8] mm/memory_hotplug: Create memory block devices after arch_add_memory() > Looks good to me. > >> >> (I would actually even prefer "memory_block_devices", because memory >> blocks have different meanins) >> > > Agree with you, this comes to my mind sometime ago :-) We have memblocks, memory_blocks ... I guess memory_block_device is unique :) > >>> >>> [...] >>> >>>> /* >>>> @@ -1106,6 +1100,13 @@ int __ref add_memory_resource(int nid, struct resource *res) >>>> if (ret < 0) >>>> goto error; >>>> >>>> + /* create memory block devices after memory was added */ >>>> + ret = hotplug_memory_register(start, size); >>>> + if (ret) { >>>> + arch_remove_memory(nid, start, size, NULL); >>> >>> Functionally, it works I think. >>> >>> But arch_remove_memory() would remove pages from zone. At this point, we just >>> allocate section/mmap for pages, the zones are empty and pages are not >>> connected to zone. >>> >>> Function zone = page_zone(page); always gets zone #0, since pages->flags is 0 >>> at this point. This is not exact. >>> >>> Would we add some comment to mention this? Or we need to clean up >>> arch_remove_memory() to take out __remove_zone()? >> >> That is precisely what is on my list next (see cover letter).This is >> already broken when memory that was never onlined is removed again. >> So I am planning to fix that independently. >> > > Sounds great :-) Especially, I suspect a lot of bugs in the area of 1. Remove memory that has never been onlined 2. Remove memory that has been onlined/offlined a couple of times 3. Remove memory that has been onlined to different zones. Will see when refactoring if my intuition is right :) > > Hope you would cc me in the following series. Sure! Thanks! -- Thanks, David / dhildenb
Powered by blists - more mailing lists