*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
