*snip*
+ pr_err("kvmi: address %016lx not mapped\n", vaddr); + return -ENOENT; + } + + /* decouple guest mapping */ + list_del(&pmp->map_list); + mutex_unlock(&fmp->lock);In kvm_dev_ioctl_map(), the fmp mutex is held across the _do_mapping() call. Is there any particular reason why here the mutex doesn't need to be held across the _do_unmapping() call? Or was that more an artifact of having a common "out_err" exit in kvm_dev_ioctl_map()? The fmp mutex: 1. protects the fmp list against concurrent access. 2. protects against teardown (one thread tries to do a mapping while another closes the file). The call to _do_mapping() - which can fail, must be done inside the critical section before we add a valid pmp entry to the list. On the other hand, inside kvm_dev_ioctl_unmap() we must extract a valid pmp entry from the list before calling _do_unmapping(). There is no real reason for protecting the _do_mapping() call, but I chose not to revert the mapping in case I hit the teardown case.
Gotcha. That makes sense. Patrick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
