Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757456AbbDPOfW (ORCPT ); Thu, 16 Apr 2015 10:35:22 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:36350 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754219AbbDPOfR (ORCPT ); Thu, 16 Apr 2015 10:35:17 -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: Thu, 16 Apr 2015 07:34:55 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Tom Gundersen Cc: Havoc Pennington , Rik van Riel , One Thousand Gnomes , Greg Kroah-Hartman , Jiri Kosina , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , "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: 3271 Lines: 66 On Thu, Apr 16, 2015 at 6:13 AM, Tom Gundersen wrote: > On 04/15/2015 10:22 PM, Andy Lutomirski wrote: >> On Wed, Apr 15, 2015 at 9:44 AM, Havoc Pennington wrote: >>> 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? > > The concepts implemented in kdbus are actually quite different from dbus1: > > Every connection to the bus has a memory pool assigned to store > incoming messages and variably sized runtime data returned by kdbus. > The pool memory is swappable, backed by a shmem file which is > associated with the bus connection. > > Also, broadcasts are opt-in, so you only receive them if you > subscribed for the specific signal. It is either sent by another > userspace task, or by the kernel itself for things like name owner > changes. In order to receive those, a connection must install a match. > By default, no-one will receive any broadcasts. > > All types of messages (unicast and broadcast) are directly stored into > a pool slice of the receiving connection, and this slice is not reused > by the kernel until userspace is finished with it and frees it. Hence, > a client which doesn't process its incoming messages will, at some > point, run out of pool space. If that happens for unicast messages, > the sender will get an EXFULL error. If it happens for a multicast > message, all we can do is drop the message, and tell the receiver how > many messages have been lost when it issues KDBUS_CMD_RECV the next > time. There's more on that in kdbus.message(7). > > Also note that there is a quota logic in kdbus which protects against > a single connection conducting a DOS against another one. Together > with the policy code, this logic prevents one peer from flooding the > pool of another peer. Communication with a 3rd party is not affected > by this, due to the fair allocation scheme of the pool logic. > > All this is explained in detail in kdbus.pool(7), but please let us > know if anything there is unclear. > This is neat, but it sounds like it will potentially add large amounts of latency under even mild memory pressure. Whose memcg does the pool use? If it's the receiver's, and if the receiver can configure a memcg, then it seems that even a single receiver could probably cause the sender to block for an unlimited amount of time. (And yes, I really hope that some day the cgroupns issues get resolved and some programs really will be able to create their own cgroups, even on systemd-using systems using the systemd-blessed configuration.) --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/