Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756754AbbDOVII (ORCPT ); Wed, 15 Apr 2015 17:08:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41515 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754958AbbDOVH6 (ORCPT ); Wed, 15 Apr 2015 17:07:58 -0400 Message-ID: <552ED310.80806@redhat.com> Date: Wed, 15 Apr 2015 17:07:28 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andy Lutomirski , Havoc Pennington CC: 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 Subject: Re: [GIT PULL] kdbus for 4.1-rc1 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> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3058 Lines: 65 On 04/15/2015 04:22 PM, Andy Lutomirski wrote: > 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. It may be useful to do the buffering (and general interception of any message that cannot be delivered) in a userspace program. Not only to get the buffers out of the kernel and into swappable memory, but also so people could re-use the same infrastructure for things like cluster communication (or communication between different containers) - the userspace daemons could take care of routing messages to and from the outside. They could also be useful to keep some of the policy stuff outside of the kernel, if only to ensure that the kernel side policy is not set in stone, and people can do things differently in the future if they want to. -- 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/