The incomplete result of mapper GetSubTree/Paths

[Ed Tanous]

On Fri, May 20, 2022 at 2:13 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> On Fri, May 20, 2022 at 11:14:15AM +0800, Lei Yu wrote:
>
> > If mapper could not guarantee the stable result, the service calling
> > mapper will have to add more complex logic to make sure it gets the
> > "full and correct" result.
>
> The issue here is around causality.  There really isn't any way to
> correctly kick this logic out to applications no matter how complex you
> make the implementation.
>
> The original mapper implementation was causally ordered but this was
> lost in the conversion to C/C++.  We should look at getting back to
> having mapper give causal order guarantees.
>

I'm not really following what causality has to do with it in Leis case.
>From my read, it looks like this is a case of "introspect takes some time
to complete, and the results for one daemon aren't expected to be added
atomically".  This exact same race is present any time an object is added
or removed from dbus, so you're right, there isn't really a way to avoid
it, aside from writing implementations that don't fail if the object count
on a connection doesn't match what the mapper gave you, which is something
we "learned" in bmcweb a long time ago.

One workaround here to cover the startup case would be to simply batch
together all objects for a given daemon in the InProgressIntrospect object
such that all of a daemons dbus paths are added to the global object
atomically, so we'd avoid the race in the startup case, but it would still
exist when new objects are created, so it doesn't completely solve the
problem, just solves it for the case above.


>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220523/0f01f3c9/attachment.htm>