In it, Linus says the following:
> No, we very much expose /proc/cmdline for a reason. System services are supposed to parse it [...] And yes, that does include "quiet" and "debug". Parsing them and doing something sane with them is not a bug, it's a feature.
In a way this Sievers guy is right but he could have been more polite in asking the kernel devs for this feature. And he needs to co-operate by cutting down the log traffic until the kernel is fixed.
I mean, it would be nice if the kernel by default could handle a simple forkbomb, but it doesn't without restricting your limits.conf fairly severely. You can blow up the system in a variety of ways that are outside of the kernel's responsibility. It's not up to the kernel devs to hack around your bad behaviour.
While systemd is obviously doing something stupid, no userspace program should be able to dump so much to the log that the machine becomes unusable. It seems like they were going to apply per-file descriptor limiting the way to they seem to limit in kernel logs on a per-log site basis.
BTW Linus agrees rate limiting is desirable here. This is the reason why I said systemd has to hold off its fire hose until the kernel can take care of it.
systemd has apparently elevated itself somewhat above the typical "user space" level, but it's still not a bad idea to harden the interface between systemd and the kernel where possible.
