Re: [GIT PULL] kdbus for 4.1-rc1

[Andy Lutomirski]

On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington <hp@xxxxxxxxx> wrote:
> On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel <riel@xxxxxxxxxx> wrote:
>> On 04/15/2015 07:06 AM, One Thousand Gnomes wrote:
>>
>>>> that anyone here does either.  In the many years I've spent working on
>>>> this, dbus has seemed to be odd, and strange, to the way that the kernel
>>>> has normally worked, because it is.  And that's not a bad thing, it's
>>>> just different, and for us to support real needs and requirements of our
>>>> users, is the requirement of the Linux kernel.
>>>
>>> There are I think a set of intertwined problems here
>>>
>>> - An efficient delivery system for multicast messages delivered locally
>>>   (be that MPI, dbus whatever - it's not "dbus or nothing")
>>>
>>> - A kernel side dynamic namespace to describe what goes where
>>>
>>> - A kernel side security model to describe who may receive what, and
>>>   which additional information/tags/cred info
>>>
>>> - Something that provides state to stuff that needs it (and probably
>>>   belongs in userspace - dbus name service etc)
>>>
>>> - Something that maps dbus and other models onto the kernel security
>>>   model (and we have tools like EBPF which are very powerful)
>>>
>>> - Something that maps the kernel layer onto models like MPI-3
>
> When trying to split apart problems, for dbus it's important to keep
> ordering guarantees.
>
> That is, with dbus if I send a broadcast message, then send a unicast
> request to another client, then drop the connection causing the bus to
> broadcast that I've dropped; then the other client will see those
> things in that order - the broadcast, then the request, and then that
> I've dropped the connection.

This leads me to a potentially interesting question: where's the
buffering?  If there's a bus with lots of untrusted clients and one of
them broadcasts data faster than all receivers can process it, where
does it go?

At least with a userspace solution, it's clear what the OOM killer
should kill when this happens.  Unless it's PID 1.  Sigh.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/