The holdout for unexporting __get_user_pages_unlocked() is its invocation in mm/process_vm_access.c: process_vm_rw_single_vec(), as this definitely _does_ seem to invoke VM_FAULT_RETRY behaviour which get_user_pages_remote() will not trigger if we were to replace it with the latter. I'm not sure how to proceed in this case - get_user_pages_remote() invocations assume mmap_sem is held so can't offer VM_FAULT_RETRY behaviour as the lock can't be assumed to be safe to release, and get_user_pages_unlocked() assumes tsk, mm are set to current, current->mm respectively so we can't use that here either. Is it important to retain VM_FAULT_RETRY behaviour here, does it matter? If it isn't so important then we can just go ahead and replace with get_user_pages_remote() and unexport away. Of course the whole idea of unexporting __get_user_pages_unlocked() might be bogus so let me know in that case also :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
