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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

(Adding Juergen.)

Hi, thanks for the resend.

David Woodhouse writes ("[PATCH v2] tools/xenstore: Do not abort xenstore-ls if 
a node disappears while iterating"):
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> When recursing, a node sometimes disappears. Deal with it and move on
> instead of aborting and failing to print the rest of what was
> requested.
> 
> Either EACCES or ENOENT may occur as the result of race conditions with
> updates; any other error should abort as before.

I think it is not safe to continue if we get a permissions error.  I
think that would mean "we were not able to determine whether this node
exists", not "this node does not exist".

So with a permissions error silently ignored, xenstore-ls might
silently produce partial output.

I reread the discussion and I'm afraid I still don't understand why
people thought that ignoring such errors would be OK.  The fact (if
true) that a spurious permissions error might result from a race is
not sufficient to justify ignoring permissions errors.

What is needed is to show that all permissions errors are fine to
ignore.  And it is obvious that there are permissions errors that are
*not* fine to ignore, so the proposition is false; and permissions
errors must cause complaint and a nonzero exit status.

Given that the code doesn't have a way to print an error message and
record the error code or exit status for later, I think the best
approach is probably exactly David's patch only without the mention of
EACCES.

Sorry to come to this so late.


On IRC, David suggested this patch for backporting.  Subject to
resolution of my comments above, that seems like a good idea to me.
(However, this comes rather too late for 4.12.1.)

Thanks,
Ian.

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