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
