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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/