[systemd-devel] bus driver on kdbus
Lennart Poettering
lennart at poettering.net
Sun Apr 13 23:39:27 PDT 2014
Lukas, Ryan,
just wanted to let you know that I am working to get rid of the bus
driverd in systemd after all, for kdbus. The reason is that leaving it
in, as it is now, is very racy, and not just theorectically, but
IRL. Ryan, you might remember the "mouse cursor" bug when running gnome
on kdbus, we showed you two weeks ago in Nuremberg, this was caused by a
race between AddMatch being processed by the driver and a subsequent
method call to another service. Quite possibly, if the driver is
otherwise busy the method call might get executed earlier, possibly
triggering a signal, which is then not subject to the match that was to
be created. This bug only showed on gdbus since only there AddMatch is
called asychronously.
Anyway, I fixed this now by making the requirement that driver calls are
executed in order on the sender side (ie. the client translates driver
bus calls into ioctls). This means the bus proxy will execute them when
a legacy dbus1 client is connected, but it is expected that a native
kdbus client will process them locally instead of ever letting them onto
the bus. Lukas, this effectively means that your initial gdbus patch was
the right way to go after all, and my request to let the driverd be in
charge was quite mislead. Sorry!
I will now remove the entirety of the driver daemon, not just
AddMatch/RemoveMatch as all but two of those calls are subject to
similar (theoretical...) races.
Ryan, I know that you really don't like having to translate the bus
driver calls on the client side, but I don't see any other way that
fixes the race and was somewhat clean to me.
Note that in our new sd-bus.h API we won't do any translations for
this. We simply expect people to invoke our high-level C APIs rather
than construct bus calls for the driver interfaces. We can do this,
since we our C library interface is entirely new anyway. This means that
the bus driver interface is thus kinda bound to using the AF_UNIX
transport. And where the kdbus transports is used ioctls are the way to
go.
A nice side effect of this change is actually that things are a bit
faster for legacy dbus1 clients. The bus driver service so far was the
one service on the system so far got the most traffic during
startup. With this change we can entirely eliminate this.
Lennart
--
Lennart Poettering, Red Hat
More information about the systemd-devel
mailing list