| |||||||||||||
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernelKroah-Hartman: AF_BUS, D-Bus, and the Linux kernelPosted Feb 10, 2013 0:07 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by khim Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
A better solution - just account for these delayed messages using normal Linux RAM accounting.
Then the OOM killer can come out and kill something (hopefully the offender) and one can use something like cgroups to fine-tune the killing priority.
(Log in to post comments)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 14:13 UTC (Sun) by renox (subscriber, #23785) [Link]
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.
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.
|
|||||||||||||