Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754858AbbDOUWm (ORCPT ); Wed, 15 Apr 2015 16:22:42 -0400 Received: from mail-la0-f52.google.com ([209.85.215.52]:33091 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751929AbbDOUWf (ORCPT ); Wed, 15 Apr 2015 16:22:35 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> From: Andy Lutomirski Date: Wed, 15 Apr 2015 13:22:12 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Havoc Pennington Cc: Rik van Riel , One Thousand Gnomes , Greg Kroah-Hartman , Jiri Kosina , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2317 Lines: 51 On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington wrote: > On Wed, Apr 15, 2015 at 12:00 PM, Rik van Riel 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/