| |||||||||||||
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernelKroah-Hartman: AF_BUS, D-Bus, and the Linux kernelPosted Feb 10, 2013 14:13 UTC (Sun) by renox (subscriber, #23785)In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by Cyberax Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Exactly my thoughts, this solves nicely the "lazy reader" issue but there is one other potential issue: the buggy/malicious writer which sends a big quantity of (big) messages, it's harder to avoid.
(Log in to post comments)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 15:46 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Surely the unruly _writer_ just blocks? Or, if they can't block, they error out when they exceed system policy limits?
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 17:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I think the question here is: "Who pays for the phone call?"
The best way to deal with DBUS flood is to use kernel's RAM accounting. And then there should be a separate decision about who is going to get "billed" for the RAM.
There are various use-cases here. For example, a privileged system process should never be stopped if its client goes dead.
|
|||||||||||||