Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966712AbbDQOzh (ORCPT ); Fri, 17 Apr 2015 10:55:37 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:33829 "EHLO mail-qc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965609AbbDQOzO (ORCPT ); Fri, 17 Apr 2015 10:55:14 -0400 MIME-Version: 1.0 In-Reply-To: <55310969.4080200@zonque.org> 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> <55310969.4080200@zonque.org> From: Havoc Pennington Date: Fri, 17 Apr 2015 10:54:43 -0400 X-Google-Sender-Auth: TvLqO2R5ZWgPIOWJV-ypHzT7a00 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Daniel Mack Cc: Tom Gundersen , Andy Lutomirski , 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" , 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: 3834 Lines: 79 On Fri, Apr 17, 2015 at 9:23 AM, Daniel Mack wrote: > > This can only happen with user-originated DBus signal messages. For > unicast messages such as method calls, the sender will actually see > -EXFULL, and no part of the message is transmitted, leaving neither side > in a confused state. Well - big asterisk, * no confused state IF the sender handles EXFULL in a reasonable way. Which it probably doesn't most of the time :-) but as you say it's no worse than it ever was. > But yes, for broadcast signal messages, we can't > reject the sender because one single peer is out of buffer space, and we > can't allow boundless allocations on the receiver either, so informing > the other side is the best we can do. If this was ever going to happen (if the limits weren't high), I do think it would be better to disconnect or throttle/backpressure somehow, instead of breaking semantics. But the trouble is figuring out how to do that... I don't know how. So the alternative is to set high limits. I think you're fine, it obviously works OK with the current userspace daemon that punts in a similar way, and unix has a long tradition of limits like this plus applications sucking at handling the "limit reached" errors. It'll all work out... > Note that dbus-daemon just drops such signals silently. So with this > counter we simply add a debug mechanism for now. There hasn't been a > consensus on how to react to such errors on the application level. The > easiest way is obviously to re-sync all your state with the peer (which > could be as easy as calling ObjectManager.GetManagedObjects() or > Properties.GetAll()). It's not realistic to expect the bulk of apps to handle this thing. Special system services such as pid 1, you probably have the expertise and time to try to carefully restore all state. Regular old apps will get confused in practice if limits are hit in practice, but people will configure the limits such that they're only hit if there's some pathology going on. >> How to handle a send error depends a lot on what's being sent... but >> if I were writing a general-purpose library wrapper, I'd be very >> tempted to hide EXFULL behind an unbounded (or very-high-bounded) >> userspace send buffer, which of course is what you were trying to >> avoid, but I am skeptical that the average app will handle this error >> sensibly. > > Actually, we see no real difference between constrained outgoing or > incoming buffers. Even with a very-high-bounded send-buffer, you still > need to deal with it running full. What I'm saying is that there's a practical difference between limits low enough to be hit in normal operation, and limits high enough that someobody has to be evil/broken before you hit them. With the "throw an error" setup, if you set the limits low enough to be hit in practice, then userspace will be buggy and break - that's my prediction at least. It's not different from say the file descriptor limits. If you crank down your allowed open descriptors such that a user session actually hits the limit, pretty much the session isn't usable. That's all I'm saying. If you wanted to be able to configure the limits low, where they'd be hit in practice, then I think you'd want to look at some solution other than tossing these errors that people will fail to handle correctly, even if that solution were complex and/or heuristic. If you set the limits high, it doesn't really matter so you can KISS. It's sort of an academic point ... tons of kernel features already have this issue. So carry on, you're good. :-) Havoc -- 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/