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: Wed, 8 Aug 2018 09:56:14 +0200 From: Oscar Salvador <osalvador@...hadventures.net> To: David Hildenbrand <david@...hat.com> Cc: Jerome Glisse <jglisse@...hat.com>, akpm@...ux-foundation.org, mhocko@...e.com, dan.j.williams@...el.com, yasu.isimatu@...il.com, logang@...tatee.com, dave.jiang@...el.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, Oscar Salvador <osalvador@...e.de> Subject: Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages On Wed, Aug 08, 2018 at 09:45:37AM +0200, David Hildenbrand wrote: > On 08.08.2018 09:38, Oscar Salvador wrote: > > On Tue, Aug 07, 2018 at 06:13:45PM -0400, Jerome Glisse wrote: > >>> And since we know for sure that memhotplug-code cannot call it with ZONE_DEVICE, > >>> I think this can be done easily. > >> > >> This might change down road but for now this is correct. They are > >> talks to enumerate device memory through standard platform mechanisms > >> and thus the kernel might see new types of resources down the road and > >> maybe we will want to hotplug them directly from regular hotplug path > >> as ZONE_DEVICE (lot of hypothetical at this point ;)). > > > > Well, I think that if that happens this whole thing will become > > much easier, since we will not have several paths for doing the same thing. > > > > Another thing that I realized is that while we want to move all operation-pages > > from remove_memory() path to offline_pages(), this can get tricky. > > > > Unless I am missing something, the devices from HMM and devm are not being registered > > against "memory_subsys" struct, and so, they never get to call memory_subsys_offline() > > and so offline_pages(). > > > > Which means that we would have to call __remove_zone() from those paths. > > But this alone will not work. > > I mean, they move it to the zone ("replacing online/offlining code"), so > they should take of removing it again. Yeah, I guess so. I mean, of course we can make this work by placing __remove_zone in devm_memremap_pages_release and hmm_devmem_release functions and make sure to call offline_mem_sections first. But sounds a bit "hacky".. Thanks -- Oscar Salvador SUSE L3
Powered by blists - more mailing lists