[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 5/7] libxl: support unmapping static shared memory areas during domain destruction



Hi Wei,

2017-11-01 23:55 GMT+08:00 Wei Liu <wei.liu2@xxxxxxxxxx>:
> On Thu, Oct 19, 2017 at 10:36:33AM +0800, Zhongze Liu wrote:
>> Add libxl__sshm_del to unmap static shared memory areas mapped by
>> libxl__sshm_add during domain creation. The unmapping process is:
>>
>> * For a master: decrease the refcount of the sshm region, if the refcount
>>   reaches 0, cleanup the whole sshm path.
>> * For a slave: unmap the shared pages, and cleanup related xs entries.
>>   decrease the refcount of the sshm region, if the refcount reaches 0,
>>   cleanup the whole sshm path.
>>
>
> This appears to be in line with what we discussed.
>
> I would like to see some explanation for: if one or more of the things
> the code does fail half way, the system is still going to be in a
> consistent state. Most notably, there isn't going to be any page leaked
> with uncleaned refs.
>

The unmapping code is invoked during the domain destruction process, so
we can't roll back. Everything done here is a "best effort": even if the code
fails half way, what I could do is to report the errors and proceed anyway.

I might be totally wrong. So please correct me.

>> +
>> +        rc = libxl__xs_transaction_commit(gc, &xt);
>> +        if (!rc) break;
>> +        if (rc < 0) goto out;
>> +         isretry = true;
>
> Indentation.

Cheers,

Zhongze Liu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.