Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966566AbbDWQqr (ORCPT ); Thu, 23 Apr 2015 12:46:47 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35854 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966336AbbDWQqo (ORCPT ); Thu, 23 Apr 2015 12:46:44 -0400 MIME-Version: 1.0 In-Reply-To: <20150423163616.GA10874@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150423130548.GA4253@kroah.com> <20150423163616.GA10874@kroah.com> From: Andy Lutomirski Date: Thu, 23 Apr 2015 09:46:22 -0700 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 To: Greg Kroah-Hartman Cc: Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "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: 2533 Lines: 62 On Thu, Apr 23, 2015 at 9:36 AM, Greg Kroah-Hartman wrote: > On Thu, Apr 23, 2015 at 03:05:48PM +0200, Greg Kroah-Hartman wrote: >> >> Andy's concerns about the capability stuff has been hashed out in >> multiple threads here. The kernel code isn't buggy as-designed or >> implemented from what we can all tell, it's just that the new >> functionality isn't liked by everyone, which is totally fair, but not a >> reason to declare that the function isn't useful. > > Andy, did I capture your existing position correctly? If we drop the > caps metadata, I'm guessing that you are ok with the code as you have > reviewed it and tested it out. So should I just add a small patch that > removes this for now? After that, we can discuss the addition of > capabilities to the metadata as an add-on feature with a future patch > and not hold up this larger merge request? No. I can fish out lists I've posted of what I personally dislike. To repeat from my not-yet-awake memory, briefly: - starttime, cmdline, and possibly other pieces of metadata are also problematic. I think starttime is especially bad because it both breaks CRIU and is IMO completely unnecessary -- I sent out draft "highpid" patches a while ago to give a much better alternative that isn't racy and won't break CRIU. But cmdline is also IMO ridiculous. - There's still an open performance question. Namely: is kdbus performant? - The policy system still sucks. Now, if we give up on the idea of anyone ever using it for anything other than dbus as it currently works, maybe this isn't a real problem. - Someone should probably convince someone who understands memory accounting that the pool mechanism accounts memory acceptably. I don't know much about mm stuff, but I think it's subject to all kinds of nasty latency and accounting abuses, some of which might even be exploited by accident. I haven't reviewed most of it. I've reviewed the metadata code (and not recently) and the pool *docs*. Shouldn't the bulk of this code have actual review before it gets merged? I've only reviewed some of it, and I didn't like what I found in that small fraction, hence my objections to caps. --Andy > > thanks, > > greg k-h -- Andy Lutomirski AMA Capital Management, LLC -- 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/