Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756373AbbDOUmK (ORCPT ); Wed, 15 Apr 2015 16:42:10 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:35819 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752022AbbDOUmD (ORCPT ); Wed, 15 Apr 2015 16:42:03 -0400 Date: Wed, 15 Apr 2015 21:41:36 +0100 From: Al Viro To: Andy Lutomirski Cc: Havoc Pennington , 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 Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415204135.GM889@ZenIV.linux.org.uk> References: <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150415085641.GH16381@kroah.com> <20150415120618.4d8d90ff@lxorguk.ukuu.org.uk> <552E8B11.4010803@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2073 Lines: 40 On Wed, Apr 15, 2015 at 01:22:12PM -0700, Andy Lutomirski wrote: > 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. ... and there is a PID 1 specimen that really likes to spew over dbus. A lot. I had never been able to find out _why_ does systemd feel like broadcasting all kinds of stuff from PID 1 - maybe somebody in this thread can answer that. For example, what's the point of broadcasting mount table updates, when * it can't hope to catch all individual changes - they _can_ get lumped together, no matter what it tries. * any process can just as easily keep track of that data on its own as it could by watching those broadcasts; parsing /proc/self/mountinfo isn't harder than parsing notifications. * you need to start with obtaining the original state somehow, or what would you apply those updates to? * if one insists on having a daemon doing such broadcasts, what the hell is the point of having PID 1 do that? Exact same logics would do just fine. Moreover, you could have one running in a namespace of your session, which is something PID 1 won't see. Sure, I understand why it wants to be aware of what's mounted and where it's mounted. Just as it wants to know what time it is. Should it broadcast a dbus message every second, just to tell everyone what had it found about the time? I'm somewhat tempted to propose AF_TWITTER - would match the style... ;-/ And frankly, this really looks like a social media braindamage - complete with status update broadcast every time a plane flies by... -- 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/