search for: get_user_pages

...ixup if a vma gets mlocked. The bit never gets removed - once a file had an mlocked vma all future pages added to it will stay stable. To complete the picture make_pages_present has to check for the host page state besides making the pages present in the linux page table. This is done by a call to get_user_pages with a pages parameter. Since the VM_LOCKED bit of the vma will be set prior to the call to get_user_pages an additional check is needed in the try_to_unmap_one function. If get_user_pages finds a discarded page it needs to remove the page from the page cache and all page tables dispite the fact th...

...ixup if a vma gets mlocked. The bit never gets removed - once a file had an mlocked vma all future pages added to it will stay stable. To complete the picture make_pages_present has to check for the host page state besides making the pages present in the linux page table. This is done by a call to get_user_pages with a pages parameter. Since the VM_LOCKED bit of the vma will be set prior to the call to get_user_pages an additional check is needed in the try_to_unmap_one function. If get_user_pages finds a discarded page it needs to remove the page from the page cache and all page tables dispite the fact th...

Hi, It recently became clear to me that there are some get_user_pages*() callers that don't fit neatly into any of the four cases that are so far listed in pin_user_pages.rst. vhost.c is one of those. Add a Case 5 to the documentation, and refer to that when converting vhost.c. Thanks to Jan Kara for helping me (again) in understanding the interaction between g...

This code was using get_user_pages*(), in approximately a "Case 5" scenario (accessing the data within a page), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basi...

...t;mm/gup: update pin_user_pages.rst for "case 3" (mmu notifiers)" [1] Changes since v1: removed references to set_page_dirty*(), in response to Souptick Joarder's review (thanks!). Cover letter for v1, edited/updated slightly: It recently became clear to me that there are some get_user_pages*() callers that don't fit neatly into any of the four cases that are so far listed in pin_user_pages.rst. vhost.c is one of those. Add a Case 5 to the documentation, and refer to that when converting vhost.c. Thanks to Jan Kara for helping me (again) in understanding the interaction between g...

...Case 2, it may still require > +FOLL_PIN, for patterns like this: > + > +Correct (uses FOLL_PIN calls): > + pin_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + unpin_user_pages() > + > +INCORRECT (uses FOLL_GET calls): > + get_user_pages() > + access the data within the pages > + set_page_dirty_lock() > + put_page() Why does this case need to pin? Why can't it just do ... get_user_pages() lock_page(page); ... modify the data ... set_page_dirty(page); unlock_page(page);

On Mon, Mar 19, 2018 at 4:29 PM, David Sterba <dsterba at suse.cz> wrote: > On Mon, Mar 19, 2018 at 05:09:28PM +0200, Michael S. Tsirkin wrote: >> Hello! >> The following code triggered by syzbot >> >> r = get_user_pages_fast(log, 1, 1, &page); >> if (r < 0) >> return r; >> BUG_ON(r != 1); >> >> Just looking at get_user_pages_fast's documentation this seems >> impossible - it is supposed to only ever return # of pages >> pinned or...

...h of these will go in first, and this allows each to stand alone. Testing: not much beyond build and boot testing has been done yet. And I'm not set up to even exercise all of it (especially the IB parts) at run time. Anyway, changes here are: * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. Then, use the new iov_iter_get_pages_use_gup() to retrieve it when it is time to release the pages. That allows choosing between put_page() and put_user_page*(). * Pass in one more piece of information to bio_release_pages: a "from_gup" parameter. Similar use as...

...h of these will go in first, and this allows each to stand alone. Testing: not much beyond build and boot testing has been done yet. And I'm not set up to even exercise all of it (especially the IB parts) at run time. Anyway, changes here are: * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter. Then, use the new iov_iter_get_pages_use_gup() to retrieve it when it is time to release the pages. That allows choosing between put_page() and put_user_page*(). * Pass in one more piece of information to bio_release_pages: a "from_gup" parameter. Similar use as...

...t. You're welcome > > > to work or propose new ideas. > > > > > > Thanks > > It seems clear we do need adaptive polling. > > Yes. > > > The difficulty with NAPI > > polling is it can't access guest memory easily. But maybe > > get_user_pages on the polled memory+NAPI polling can work. > > You mean something like zerocopy? Looks like we can do busy polling without > it. I mean something like https://patchwork.kernel.org/patch/8707511/. > > Thanks How does this patch work? vhost_vq_avail_empty can sleep, you are calling...

...t. You're welcome > > > to work or propose new ideas. > > > > > > Thanks > > It seems clear we do need adaptive polling. > > Yes. > > > The difficulty with NAPI > > polling is it can't access guest memory easily. But maybe > > get_user_pages on the polled memory+NAPI polling can work. > > You mean something like zerocopy? Looks like we can do busy polling without > it. I mean something like https://patchwork.kernel.org/patch/8707511/. > > Thanks How does this patch work? vhost_vq_avail_empty can sleep, you are calling...

Since when we are using the m2p_override it is not true anymore that the mmap''ed area doesn''t have corresponsing struct pages. Removing the VM_PFNMAP flag makes get_user_pages work on the mmap''ed user vma. An example test case would be using a Xen userspace block backend (QDISK) on a file on NFS using O_DIRECT. The patch should be backported back to 2.6.38. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- drivers/xen/gntdev.c |...

...; > > > > > > > > Thanks > > > > It seems clear we do need adaptive polling. > > > Yes. > > > > > > > The difficulty with NAPI > > > > polling is it can't access guest memory easily. But maybe > > > > get_user_pages on the polled memory+NAPI polling can work. > > > You mean something like zerocopy? Looks like we can do busy polling without > > > it. I mean something like https://patchwork.kernel.org/patch/8707511/. > > > > > > Thanks > > How does this patch work? vhos...

...ress writing to registered DMA"); return 0; @@ -376,7 +376,7 @@ static u32 do_dma(struct lguest *srclg, const struct lguest_dma *src, * we only want a single page. But it works, and returns the * number of pages. Note that we're holding the destination's * mmap_sem, as get_user_pages() requires. */ - if (get_user_pages(dstlg->tsk, dstlg->mm, + if (get_user_pages(lguest_task(dstlg), dstlg->mm, dst->addr[i], 1, 1, 1, pages+i, NULL) != 1) { /* This means the destination gave us a bogus buffer */ @@ -469,9 +469,9 @@ static int dma_transfer(struct lg...

...ress writing to registered DMA"); return 0; @@ -376,7 +376,7 @@ static u32 do_dma(struct lguest *srclg, const struct lguest_dma *src, * we only want a single page. But it works, and returns the * number of pages. Note that we're holding the destination's * mmap_sem, as get_user_pages() requires. */ - if (get_user_pages(dstlg->tsk, dstlg->mm, + if (get_user_pages(lguest_task(dstlg), dstlg->mm, dst->addr[i], 1, 1, 1, pages+i, NULL) != 1) { /* This means the destination gave us a bogus buffer */ @@ -469,9 +469,9 @@ static int dma_transfer(struct lg...

...8 Jul 25 02:15:02 vega2008 kernel: [<c046e9c9>] ? flush_old_exec+0x4f8/0x777 Jul 25 02:15:02 vega2008 kernel: [<c046dfcf>] ? kernel_read+0x32/0x43 Jul 25 02:15:02 vega2008 kernel: [<c0490e60>] ? load_elf_binary+0x359/0x1152 Jul 25 02:15:02 vega2008 kernel: [<c045a6ee>] ? get_user_pages+0x2d5/0x35c Jul 25 02:15:02 vega2008 kernel: [<c04570d2>] ? page_address+0x78/0x98 Jul 25 02:15:02 vega2008 kernel: [<c045735a>] ? kmap_high+0x19/0x16b Jul 25 02:15:02 vega2008 kernel: [<c04570d2>] ? page_address+0x78/0x98 Jul 25 02:15:02 vega2008 kernel: [<c046dced>] ?...

On Sat, May 30, 2020 at 5:13 AM John Hubbard <jhubbard at nvidia.com> wrote: > > There are four cases listed in pin_user_pages.rst. These are > intended to help developers figure out whether to use > get_user_pages*(), or pin_user_pages*(). However, the four cases > do not cover all the situations. For example, drivers/vhost/vhost.c > has a "pin, write to page, set page dirty, unpin" case. > > Add a fifth case, to help explain that there is a general pattern > that requires pin_user_p...

...ggested for this which is to steal the necessary # of entries off the list. > > Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc I'd do get_user_pages really. You don't want pages split, etc. > by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. > > The max size of the kmalloc-ed memory is 4MB, which gives us the...

Hello! The following code triggered by syzbot r = get_user_pages_fast(log, 1, 1, &page); if (r < 0) return r; BUG_ON(r != 1); Just looking at get_user_pages_fast's documentation this seems impossible - it is supposed to only ever return # of pages pinned or errno. However, poking at code, I see at least one path that...

...his which is to steal the necessary # of entries off the list. > > > Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc > > I'd do get_user_pages really. You don't want pages split, etc. Oops sorry. I meant get_free_pages . > > > > by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. > > > >...