[systemd-devel] bus driver on kdbus

[Lukasz Skalski]

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
l.skalski at samsung.com