Re: [RFC PATCH v4 02/18] add memory map/unmap support for VM introspection on the guest side

[Patrick Colp <patrick.colp@oracle.com>]

*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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>