Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort xenstore-ls if a node disappears while iterating

[Jürgen Groß <jgross@xxxxxxxx>]

On 19.03.20 21:40, David Woodhouse wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
>
> The do_ls() function has somewhat inconsistent handling of errors.
>
> If reading the node's contents with xs_read() fails, then do_ls() will
> just quietly not display the contents.
>
> If reading the node's permissions with xs_get_permissions() fails, then
> do_ls() will print a warning, continue, and ultimately won't exit with
> an error code (unless another error happens).
>
> If recursing into the node with xs_directory() fails, then do_ls() will
> abort immediately, not printing any further nodes.
>
> For persistent failure modes — such as ENOENT because a node has been
> removed, or EACCES because it has had its permisions changed since the
> xs_directory() on the parent directory returned its name — it's
> obviously quite likely that if either of the first two errors occur for
> a given node, then so will the third and thus xenstore-ls will abort.
>
> The ENOENT one is actually a fairly common case, and has caused tools to
> fail to clean up a network device because it *apparently* already
> doesn't exist in xenstore.
>
> There is a school of thought that says, "Well, xenstore-ls returned an
> error. So the tools should not trust its output."
>
> The natural corollary of this would surely be that the tools must re-run
> xenstore-ls as many times as is necessary until its manages to exit
> without hitting the race condition. I am not keen on that conclusion.
>
> For the specific case of ENOENT it seems reasonable to declare that,
> but for the timing, we might as well just not have seen that node at
> all when calling xs_directory() for the parent. By ignoring the error,
> we give acceptable output.
Have you thought about the possibility to do the complete handling in a
single transaction? This would ensure a complete consistent picture
from the time the operation has started. Any inconsistency should be
reported as an error then.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel