On 04/14/2014 08:39 AM, Lennart Poettering wrote:
Lukas, Ryan,
Hi Lennart, 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.
Yes, you're right, I also noticed that something is wrong with AddMatch.
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!
Ok, so I'll prepare and upload [1] new version of my patchset for gdbus (with translating all bus calls into ioctls directly in library), as soon as it's possible.
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.
Ryan, what do you think about it?
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
[1] https://bugzilla.gnome.org/show_bug.cgi?id=721861 Thanks, -- Lukasz Skalski Samsung R&D Institute Poland Samsung Electronics [email protected] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
