Re: [Xen-devel] [PATCH for-4.8] tools/oxenstored: Avoid allocating invalid transaction ids

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/10/16 13:02, Wei Liu wrote:
> On Wed, Oct 26, 2016 at 10:46:17AM +0100, David Scott wrote:
>>> On 26 Oct 2016, at 10:34, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>>>
>>> The transaction id of 0 is reserved, meaning "not in a transaction".  It is 
>>> up
>>> to the xenstored server to allocate transaction ids.  While oxenstored 
>>> starts
>>> its ids at 1, but insufficient care is taken with truncation cases.
>>>
>>> A 32bit oxenstored has an int with 31 bits of width, meaning that the
>>> transaction id will wrap around to 0 after 2 billion transactions.
>>>
>>> A 64bit oxenstored has an int with 63 bits of width, meaning that once 4
>>> billion transactions are used, the allocated id will be truncated when 
>>> written
>>> into the uin32_t field in the ring.  This causes the client to reply with 
>>> the
>>> truncated id, breaking any further attempt to use any transactions.
>>>
>>> Limit all transaction ids to the range between 1 and 0x7ffffffe.  This is 
>>> the
>>> best which can be done without making oxenstored depend on Stdint or 
>>> Cstruct,
>>> yet still work for 32bit builds.
>> Good catch, looks good to me!
>>
>>> Also check that the proposed new transaction id isn't currently in use.  For
>>> the first 2 billion transactions there is no chance of a collision, and 
>>> after
>>> that, the chance is at most 20 (the default open transaction quota) in 2
>>> billion.
>> That makes sense to me. There seems little chance of the hash table filling 
>> up when the quota is set to 20 :-)
>>
>> Acked-by: David Scott <dave@xxxxxxxxxx>
>>
> Thanks for the quick turnaround.

Ian: It occurs to me that this should also be a backport candidate to
older trees.

~Andrew

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