Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933205AbbHITAa (ORCPT ); Sun, 9 Aug 2015 15:00:30 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:45981 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933161AbbHITA2 (ORCPT ); Sun, 9 Aug 2015 15:00:28 -0400 Date: Sun, 9 Aug 2015 12:00:27 -0700 From: Greg Kroah-Hartman To: Linus Torvalds Cc: Daniel Mack , 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 Subject: Re: kdbus: to merge or not to merge? Message-ID: <20150809190027.GA24185@kroah.com> References: <55C3A403.8020202@zonque.org> <55C4C35A.4070306@zonque.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2467 Lines: 49 On Fri, Aug 07, 2015 at 06:26:31PM +0300, Linus Torvalds wrote: > User space memory allocation is not AT ALL the same thing as kdbus. > Kernel allocations are very very different from user allocations. We > have reasonable, fairly tested, and generic models for handling user > space memory allocation issues - limiting, debugging, failing, and > handling catastrophes (ie oom). And no, even that doesn't always work > perfectly, but at least there is a *lot* of support for it, and this > is not some special case. The memory in this case is a shmem file that is created by the kernel, but on behalf of the bus client task, which will eventually own it. As discussed with the mm developers, the same logic for accounting, OOM handling, etc. applies to the kdbus shmem buffers, as they are written to from the context of another task.? If this is mistaken, then yes, you are right, and the code will have to be changed. > This discussion has been full of kdbus people ignoring Andy saying "it > worked with the user space version, it killed the machine with kdbus". > And now people trying to claim the issues are the same. HELL NO. Andy found some great bugs with regards to flooding the bus with requests, which has not been ignored at all.? The same issue is present in dbus today, but the kdbus code runs faster and more messages were being sent than the current userspace dbus daemon, so the machine becomes unresponsive easier. The issue is with userspace clients opting in to receive all NameOwnerChanged messages on the bus, which is not a good idea as they constantly get woken up and process them, which is why the CPU was pegged.? This issue should now be fixed in Rawhide for some of the packages we found that were doing this. Maintainers of other packages have been informed.? End result, no one has ever really tested sending "bad" messages to the current system as all existing dbus users try to be "good actors", thanks to Andy's testing, these apps should all now become much more robust. In chatting with Daniel on IRC, he is writing up a summary of how the kdbus memory pools work in more detail, and he said he would sent that out in a day or so, so that everyone can review. thanks, greg k-h -- 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/