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: Mon, 2 Mar 2020 13:53:08 +0100 From: David Hildenbrand <david@...hat.com> To: Michal Hocko <mhocko@...nel.org> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, virtio-dev@...ts.oasis-open.org, virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, "Michael S . Tsirkin" <mst@...hat.com>, Oscar Salvador <osalvador@...e.com>, Pavel Tatashin <pasha.tatashin@...een.com>, Wei Yang <richard.weiyang@...il.com>, Dan Williams <dan.j.williams@...el.com>, Qian Cai <cai@....pw> Subject: Re: [PATCH RFC v4 08/13] mm/memory_hotplug: Introduce offline_and_remove_memory() On 02.03.20 13:48, Michal Hocko wrote: > On Tue 25-02-20 15:27:28, David Hildenbrand wrote: >> On 25.02.20 15:11, Michal Hocko wrote: >>> On Thu 12-12-19 18:11:32, David Hildenbrand wrote: >>>> virtio-mem wants to offline and remove a memory block once it unplugged >>>> all subblocks (e.g., using alloc_contig_range()). Let's provide >>>> an interface to do that from a driver. virtio-mem already supports to >>>> offline partially unplugged memory blocks. Offlining a fully unplugged >>>> memory block will not require to migrate any pages. All unplugged >>>> subblocks are PageOffline() and have a reference count of 0 - so >>>> offlining code will simply skip them. >>>> >>>> All we need an interface to trigger the "offlining" and the removing in a >>>> single operation - to make sure the memory block cannot get onlined by >>>> user space again before it gets removed. >>> >>> Why does that matter? Is it really likely that the userspace would >>> interfere? What would be the scenario? >> >> I guess it's not that relevant after all (I think this comment dates >> back to the times where we didn't have try_remove_memory() and could >> actually BUG_ON() in remove_memory() if there would have been a race). >> Can drop that part. >> >>> >>> Or is still mostly about not requiring callers to open code this general >>> patter? >> >> From kernel module context, I cannot get access to the actual memory >> block device (find_memory_block()) and call the device_unregister(). >> >> Especially, also the device hotplug lock is not exported. So this is a >> clean helper function to be used from kernel module context. (e.g., also >> hyper-v showed interest for using that) > > Fair enough. > I'll send a v1 shortly, I rephrased the description to make this clear. Thanks! -- Thanks, David / dhildenb
Powered by blists - more mailing lists