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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

Applied.

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