Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754313AbbHJREW (ORCPT ); Mon, 10 Aug 2015 13:04:22 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:36162 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753695AbbHJRET (ORCPT ); Mon, 10 Aug 2015 13:04:19 -0400 MIME-Version: 1.0 In-Reply-To: <55C7D02A.9060905@zonque.org> References: <55C3A403.8020202@zonque.org> <55C4C35A.4070306@zonque.org> <20150809190027.GA24185@kroah.com> <55C7D02A.9060905@zonque.org> Date: Mon, 10 Aug 2015 10:04:18 -0700 X-Google-Sender-Auth: _7CKmWNgcYlTqfeLG-WCi8uTOVs Message-ID: Subject: Re: kdbus: to merge or not to merge? From: Linus Torvalds To: Daniel Mack Cc: Greg Kroah-Hartman , Tom Gundersen , "Kalle A. Sandstrom" , Borislav Petkov , One Thousand Gnomes , Havoc Pennington , Djalal Harouni , Andy Lutomirski , "linux-kernel@vger.kernel.org" , "Eric W. Biederman" , cee1 , David Herrmann , linux-mm 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: 2340 Lines: 49 On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack wrote: > > The kdbus implementation is actually comparable to two tasks X and Y > which both have their own buffer file open and mmap()ed, and they both > pass their FD to the other side. If X now writes to Y's file, and that > is causing a page fault, X is accounted for it, correct? No. With shared memory, there's no particularly obvious accounting rules. In particular, when somebody maps an already allocated page, it's basically a no-op from a memory allocation standpoint. The whole "this is equivalent to the user space deamon" argument is bogus. Shared memory is very very different from just sending messages (copying the buffers) and is generally much harder to get a handle on. And thats' what you should be comparing to. The old "communicate over a unix domain socket" had pretty clear accounting rules, and while unix domain sockets have some horribly nasty issues (most are about passing fd's around) that isn't one of them. Anyway, the real issue for me here is that Andy is reporting all these actual real problems that happen in practice, and the developer replies are dismissing them on totally irrelevant grounds ("this should be equivalent to something entirely different that nobody ever does" or "well, people could opt out, even if they didn't" yadda yadda yadda). For example, the whole "tasks X and Y communicate over shmem" is irrelevant. Normally, when people write those kinds of applications, they are just regular applications. If they have issues, nobody else cares. Andy's concern is about one of X/Y being a system daemon and tricking it into doing bad things ends up effectively killing the system - whether the *kernel* is alive or not and did the right thing is almost entirely immaterial. So please. When Andy sends a bug report with a exploit that kills his system, just stop responding with irrelevant theoretical arguments. It is not appropriate. Instead, acknowledge the problem and work on fixing it, none of this "but but but it's all the same" crap. Linus -- 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/