Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754952AbbHFIFI (ORCPT ); Thu, 6 Aug 2015 04:05:08 -0400 Received: from mail-la0-f43.google.com ([209.85.215.43]:34942 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754609AbbHFIE7 (ORCPT ); Thu, 6 Aug 2015 04:04:59 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 6 Aug 2015 10:04:57 +0200 Message-ID: Subject: Re: kdbus: to merge or not to merge? From: David Herrmann To: Andy Lutomirski Cc: Linus Torvalds , Andy Lutomirski , "linux-kernel@vger.kernel.org" , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack , "Kalle A. Sandstrom" , Borislav Petkov , cee1 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: 2803 Lines: 77 Hi On Wed, Aug 5, 2015 at 10:11 PM, Andy Lutomirski wrote: > On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann wrote: >> Hi >> >> On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski wrote: >>> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote: >>>> This is a bug in the proxy (which is already fixed). >>> >>> Should I expect to see it in Rawhide soon? >> >> Use this workaround until it does: >> >> $ DBUS_SYSTEM_BUS_ADDRESS="kernel:path=/sys/fs/kdbus/0-system/bus" >> ./your-binary >> > > Which binary is supposed to be run like that? Your test. >>> Anyway, the broadcasts that I intended to exercise were >>> KDBUS_ITEM_ID_REMOVE. Those appear to be broadcast to everyone, >>> irrespective of "policy", so long as the "match" thingy allows it. >> >> Matches are opt-in, not opt-out. Nobody will get this message unless >> they opt in. >> > > And what opts in? Either something's broken, or there's a different > scalabilty problem, or a whole pile of kdbus-using programs in Fedora > Rawhide do, in fact, opt in. See Daniel's explanation. If applications subscribe to all notifications, they get what they asked for. I recommend filing bug reports for the applications in question. > Given that all existing prototype userspace that I'm aware of > (systemd and its consumers) apparently opts in, I don't really care > that the feature is opt-in. This is just plain wrong. Out of the dozens of dbus applications, you found like 9 which are buggy? Two of them are already fixed, the maintainers of the other ones notified. I'd be interested where you got this notion that "all existing prototype userspace [...] opts in". > Also, given things like this: > > commit d27c8057699d164648b7d8c1559fa6529998f89d > Author: David Herrmann > Date: Tue May 26 09:30:14 2015 +0200 > > kdbus: forward ID notifications to everyone > > it really does seem to me that the point of these ID notifications is > for everyone to get them. It's not. This patch just opens the policy so everyone can see those notifications. By default, it's not delivered to anyone. > Also, you haven't addressed the memory usage issues -- ..because it doesn't change anything. If your IPC is message based and async, _someone_ needs to buffer. I don't see the difference between buffering locally on !EPOLLOUT or buffering in a shmem pool. In both cases, clients have control over the buffer size. If you disagree, please _elaborate_. Thanks David -- 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/