Re: [Xen-devel] [PATCH v4 04/12] xenstore: add per-node generation counter

[Juergen Gross <jgross@xxxxxxxx>]

On 09/01/17 15:38, Jan Beulich wrote:
>>>> On 05.12.16 at 08:48, <JGross@xxxxxxxx> wrote:
>> --- a/tools/xenstore/include/xenstore_lib.h
>> +++ b/tools/xenstore/include/xenstore_lib.h
>> @@ -44,6 +44,7 @@ struct xs_permissions
>>  
>>  /* Header of the node record in tdb. */
>>  struct xs_tdb_record_hdr {
>> +    uint64_t generation;
>>      uint32_t num_perms;
>>      uint32_t datalen;
>>      uint32_t childlen;
> 
> After quite a bit of debugging I think I now understand that this is
> the reason for a startup SEGV I'm getting from 4.8 xenstored after
> that same system has run unstable xenstored. The above

How are you starting xenstored? I can't see how xenstored started
by Xen's scripts will see a file with a tdb dump. Those should be
deleted by the start scripts of Xen.

The only way I can see this would happen is if you kill a running
xenstored and start another one manually. As this procedure will drop
all registered xenstore watches I think we rather should drop support
for starting xenstored with a populated tdb file.


Juergen

> represents a binary change (and, perhaps even worse, one making
> the layout no longer match between 32- and 64-bit tool stacks) to
> TDB layout, yet the commit didn't bump TDB_VERSION. I'll submit a
> patch to bump the version in a minute, but I'll leave it to others to
> judge about the layout aspect.
> 
> Now that's only the surface part of the problem. Having looked into
> check_store_() during debugging, I think it is quite ugly for that
> function to infinitely invoke itself recursively if it finds (in my case here,
> but I think this is just one example) all zeros as child names (leading to
> child_name() producing "/", i.e. the node name its top level invocation
> from check_store() passed).
> 
> Jan
> 


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