search for: unmap_mapping_pages

On Fri, Nov 06, 2020 at 01:26:50PM -0800, Ralph Campbell wrote: > > On 11/6/20 12:03 AM, Christoph Hellwig wrote: >> I hate the extra pin count magic here. IMHO we really need to finish >> off the series to get rid of the extra references on the ZONE_DEVICE >> pages first. > > First, thanks for the review comments. > > I don't like the extra refcount

...ops will > > get call and from there you call hmm_mirror following its API. > > > > Oh also mark the vma with VM_WIPEONFORK to avoid any issue if the > > inspector process use fork() (you could support fork but then you would > > need to mark the vma as SHARED and use unmap_mapping_pages instead of > > zap_page_range). > > > > > > There everything you want to do with already upstream mm code. > > I'm the author of remote mapping, so I owe everybody some explanations. > My requirement was to map pages from one QEMU process to another QEMU &gt...

...l reference count of one. The problem I see is that there are 3 states that are important: a) memory is free and not allocated to any file (page_ref_count() == 0). b) memory is allocated to a file and in the page cache (page_ref_count() == 1). c) some gup() or I/O has a reference even after calling unmap_mapping_pages() (page_ref_count() > 1). ext4_break_layouts() basically waits until the page_ref_count() == 1 with put_page() calling wake_up_var(&page->_refcount) to wake up ext4_break_layouts(). The current code doesn't seem to distinguish (a) and (b). If we want to use the 0->1 ref...

From: Mircea C?rjaliu <mcirjaliu at bitdefender.com> The following two new mm exports are introduced: * mm_remote_map(struct mm_struct *req_mm, unsigned long req_hva, unsigned long map_hva) * mm_remote_unmap(unsigned long map_hva) * mm_remote_reset(void) * rmap_walk_remote(struct page *page, struct rmap_walk_control *rwc) This patch