Messages in this thread | | | Subject | Re: [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address | From | Jason Wang <> | Date | Mon, 11 Mar 2019 15:21:41 +0800 |
| |
On 2019/3/9 上午3:11, Andrea Arcangeli wrote: > On Fri, Mar 08, 2019 at 05:13:26PM +0800, Jason Wang wrote: >> Actually not wrapping around, the pages for used ring was marked as >> dirty after a round of virtqueue processing when we're sure vhost wrote >> something there. > Thanks for the clarification. So we need to convert it to > set_page_dirty and move it to the mmu notifier invalidate but in those > cases where gup_fast was called with write=1 (1 out of 3). > > If using ->invalidate_range the page pin also must be removed > immediately after get_user_pages returns (not ok to hold the pin in > vmap until ->invalidate_range is called) to avoid false positive gup > pin checks in things like KSM, or the pin must be released in > invalidate_range_start (which is called before the pin checks). > > Here's why: > > /* > * Check that no O_DIRECT or similar I/O is in progress on the > * page > */ > if (page_mapcount(page) + 1 + swapped != page_count(page)) { > set_pte_at(mm, pvmw.address, pvmw.pte, entry); > goto out_unlock; > } > [..] > set_pte_at_notify(mm, pvmw.address, pvmw.pte, entry); > ^^^^^^^ too late release the pin here, the > above already failed > > ->invalidate_range cannot be used with mutex anyway so you need to go > back with invalidate_range_start/end anyway, just the pin must be > released in _start at the latest in such case.
Yes.
> > My prefer is generally to call gup_fast() followed by immediate > put_page() because I always want to drop FOLL_GET from gup_fast as a > whole to avoid 2 useless atomic ops per gup_fast.
Ok, will do this (if I still plan to use vmap() in next version).
> > I'll write more about vmap in answer to the other email. > > Thanks, > Andrea
Thanks
| |