search for: pin_user_pages

This is based on Linux 5.7, plus one prerequisite patch: "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...

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 get_user_pages() and page writeback [1]. This is based on today's mmotm, which has a nearby patch to...

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. > > A...

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 expl...

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 expl...

...se a problem. Case 5 may be considered a > +superset of Case 1, plus Case 2, plus anything that invokes that pattern. In > +other words, if the code is neither Case 1 nor 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...

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]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pag...

...gling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have multiple pin_user_pages calls to make up the entire region. This way it's easier to track and account the pages already mapped, particularly for clean-up in the error path. Fixes: 20453a45fb06 ("vhost: introduce vDPA-based backend") Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> --- drivers/vho...

...gling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have multiple pin_user_pages calls to make up the entire region. This way it's easier to track and account the pages already mapped, particularly for clean-up in the error path. Fixes: 4c8cf31885f6 ("vhost: introduce vDPA-based backend") Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> --- Changes in v...

...t; + locked = atomic64_add_return(npages, &dev->mm->pinned_vm); > lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT; > - if (npages + atomic64_read(&dev->mm->pinned_vm) > lock_limit) { > - ret = -ENOMEM; > - goto unlock; > - } > > - pinned = pin_user_pages(msg->uaddr & PAGE_MASK, npages, gup_flags, > - page_list, vmas); > - if (npages != pinned) { > - if (pinned < 0) { > - ret = pinned; > - } else { > - unpin_user_pages(page_list, pinned); > - ret = -ENOMEM; > - } > - goto unlock; > + if (locked &g...

...ng)iovec->iov_base, >+ pages_in_seg, FOLL_GET, user_pages, >+ NULL) != pages_in_seg) >+ return -1; Reading the get_user_pages() documentation, this should pin the user pages, so we should be fine if we then expose them in the virtqueue. But reading Documentation/core-api/pin_user_pages.rst it seems that drivers should use "pin_user_pages*() for DMA-pinned pages", so I'm not sure what we should do. Additional advice would be great! Anyway, when we are done using the pages, we should call put_page() or unpin_user_page() depending on how we pin them. >+ >+ fo...

...ost_vdpa_release()? > > > > > > > > > > Please consider the following lifecycle of the vdpa device: > > > > > > 1. vhost_vdpa_open > > > vhost_vdpa_alloc_domain > > > > > > 2. vhost_vdpa_pa_map > > > pin_user_pages > > > vhost_vdpa_map > > > iommu_map > > > > > > 3. kill QEMU > > > > > > 4. vhost_vdpa_release > > > vhost_vdpa_free_domain > > > > > > In this case, we have no opportunity to invoke unpin_user_...