search for: gup

...irtualization/msg36824.html. But looks > like you have some concern about its locality. Right and it doesn't go away. You'll need to come up with a test that messes it up and triggers a worst-case scenario, so we can measure how bad is that worst-case. > But the problem still there, GUP can do page fault, so still need to > synchronize it with MMU notifiers. I think the idea was, if GUP would need a pagefault, don't do a GUP and do to/from user instead. Hopefully that will fault the page in and the next access will go through. > The solution might be something like &gt...

On Sun, Aug 04, 2019 at 04:07:17AM -0400, Michael S. Tsirkin wrote: > > > > Also, why can't this just permanently GUP the pages? In fact, where > > > > does it put_page them anyhow? Worrying that 7f466 adds a get_user page > > > > but does not add a put_page?? > > > > You didn't answer this.. Why not just use GUP? > > > > Jason > > Sorry I misunderstood...

On Sun, Aug 04, 2019 at 04:07:17AM -0400, Michael S. Tsirkin wrote: > > > > Also, why can't this just permanently GUP the pages? In fact, where > > > > does it put_page them anyhow? Worrying that 7f466 adds a get_user page > > > > but does not add a put_page?? > > > > You didn't answer this.. Why not just use GUP? > > > > Jason > > Sorry I misunderstood...

On Thu, Mar 07, 2019 at 10:34:39AM -0500, Michael S. Tsirkin wrote: > On Thu, Mar 07, 2019 at 10:45:57AM +0800, Jason Wang wrote: > > > > On 2019/3/7 ??12:31, Michael S. Tsirkin wrote: > > > > +static void vhost_set_vmap_dirty(struct vhost_vmap *used) > > > > +{ > > > > + int i; > > > > + > > > > + for (i = 0; i <

...bfs/tmpfs, would be nice if there > was a clean way to do that. > > Now assuming we don't nak the use on ext4 VM_SHARED and we stick to > set_page_dirty_lock for such case: could you recap how that > __writepage ext4 crash was solved if try_to_free_buffers() run on a > pinned GUP page (in our vhost case try_to_unmap would have gotten rid > of the pins through the mmu notifier and the page would have been > freed just fine). So for the above the easiest thing is to call set_page_dirty() from the mmu notifier callback. It is always safe to use the non locking variant f...

...bfs/tmpfs, would be nice if there > was a clean way to do that. > > Now assuming we don't nak the use on ext4 VM_SHARED and we stick to > set_page_dirty_lock for such case: could you recap how that > __writepage ext4 crash was solved if try_to_free_buffers() run on a > pinned GUP page (in our vhost case try_to_unmap would have gotten rid > of the pins through the mmu notifier and the page would have been > freed just fine). So for the above the easiest thing is to call set_page_dirty() from the mmu notifier callback. It is always safe to use the non locking variant f...

..._dirty if it's anon/hugetlbfs/tmpfs, would be nice if there was a clean way to do that. Now assuming we don't nak the use on ext4 VM_SHARED and we stick to set_page_dirty_lock for such case: could you recap how that __writepage ext4 crash was solved if try_to_free_buffers() run on a pinned GUP page (in our vhost case try_to_unmap would have gotten rid of the pins through the mmu notifier and the page would have been freed just fine). The first two things that come to mind is that we can easily forbid the try_to_free_buffers() if the page might be pinned by GUP, it has false positives wi...

...MAP) and > added speculation barriers there's a chance we can win by accessing > memory through the kernel address. You think copy_to_user will be more expensive than the minimum two atomics required to synchronize with another thread? > > Also, why can't this just permanently GUP the pages? In fact, where > > does it put_page them anyhow? Worrying that 7f466 adds a get_user page > > but does not add a put_page?? You didn't answer this.. Why not just use GUP? Jason

...MAP) and > added speculation barriers there's a chance we can win by accessing > memory through the kernel address. You think copy_to_user will be more expensive than the minimum two atomics required to synchronize with another thread? > > Also, why can't this just permanently GUP the pages? In fact, where > > does it put_page them anyhow? Worrying that 7f466 adds a get_user page > > but does not add a put_page?? You didn't answer this.. Why not just use GUP? Jason

On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: > Btw, I come up another idea, that is to disable preemption when vhost thread > need to access the memory. Then register preempt notifier and if vhost > thread is preempted, we're sure no one will access the memory and can do the > cleanup. Great, more notifiers :( Maybe can live with 1- disable preemption while using

On Fri, Aug 02, 2019 at 05:40:07PM +0800, Jason Wang wrote: > Btw, I come up another idea, that is to disable preemption when vhost thread > need to access the memory. Then register preempt notifier and if vhost > thread is preempted, we're sure no one will access the memory and can do the > cleanup. Great, more notifiers :( Maybe can live with 1- disable preemption while using

...get_user_pages) is going to be added. That's one bool too many, > > because it's not desirable have calls of the form: > > All pages releases by bio_release_pages should come from > get_get_user_pages, so I don't really see the point here. No they do not all comes from GUP for see various callers of bio_check_pages_dirty() for instance iomap_dio_zero() I have carefully tracked down all this and i did not do anyconvertion just for the fun of it :) Cheers, J?r?me

...get_user_pages) is going to be added. That's one bool too many, > > because it's not desirable have calls of the form: > > All pages releases by bio_release_pages should come from > get_get_user_pages, so I don't really see the point here. No they do not all comes from GUP for see various callers of bio_check_pages_dirty() for instance iomap_dio_zero() I have carefully tracked down all this and i did not do anyconvertion just for the fun of it :) Cheers, J?r?me

...+0200, Christoph Hellwig wrote: > On Mon, Jul 29, 2019 at 04:57:21PM -0400, Jerome Glisse wrote: > > > All pages releases by bio_release_pages should come from > > > get_get_user_pages, so I don't really see the point here. > > > > No they do not all comes from GUP for see various callers > > of bio_check_pages_dirty() for instance iomap_dio_zero() > > > > I have carefully tracked down all this and i did not do > > anyconvertion just for the fun of it :) > > Well, the point is _should_ not necessarily do. iomap_dio_zero adds t...

...e-api/pin_user_pages.rst index 4675b04e8829..b9f2688a2c67 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -171,6 +171,26 @@ If only struct page data (as opposed to the actual memory contents that a page is tracking) is affected, then normal GUP calls are sufficient, and neither flag needs to be set. +CASE 5: Pinning in order to write to the data within the page +------------------------------------------------------------- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +access page's data, unpi...

...e-api/pin_user_pages.rst index 4675b04e8829..6068266dd303 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -171,6 +171,24 @@ If only struct page data (as opposed to the actual memory contents that a page is tracking) is affected, then normal GUP calls are sufficient, and neither flag needs to be set. +CASE 5: Pinning in order to write to the data within the page +------------------------------------------------------------- +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, +write to a page's data,...

...> index 4675b04e8829..b9f2688a2c67 100644 > --- a/Documentation/core-api/pin_user_pages.rst > +++ b/Documentation/core-api/pin_user_pages.rst > @@ -171,6 +171,26 @@ If only struct page data (as opposed to the actual memory contents that a page > is tracking) is affected, then normal GUP calls are sufficient, and neither flag > needs to be set. > > +CASE 5: Pinning in order to write to the data within the page > +------------------------------------------------------------- > +Even though neither DMA nor Direct IO is involved, just a simple case of "pin, > +...

On Thu, Mar 07, 2019 at 10:45:57AM +0800, Jason Wang wrote: > > On 2019/3/7 ??12:31, Michael S. Tsirkin wrote: > > > +static void vhost_set_vmap_dirty(struct vhost_vmap *used) > > > +{ > > > + int i; > > > + > > > + for (i = 0; i < used->npages; i++) > > > + set_page_dirty_lock(used->pages[i]); > > This seems to rely on

On Thu, Mar 07, 2019 at 10:45:57AM +0800, Jason Wang wrote: > > On 2019/3/7 ??12:31, Michael S. Tsirkin wrote: > > > +static void vhost_set_vmap_dirty(struct vhost_vmap *used) > > > +{ > > > + int i; > > > + > > > + for (i = 0; i < used->npages; i++) > > > + set_page_dirty_lock(used->pages[i]); > > This seems to rely on

...his series. I was anticipating these going through the mm tree as they > depend on a cleanup patch there and the IB changes are very minor. But they > could just as well go through the IB tree. > > NOTE: This series depends on my clean up patch to remove the write parameter > from gup_fast_permitted()[1] > > HFI1, qib, and mthca, use get_user_pages_fast() due to it performance > advantages. These pages can be held for a significant time. But > get_user_pages_fast() does not protect against mapping of FS DAX pages. This I don't get - if you do lock down long t...