I think Linus gets to the point build right or get out of the way. http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

1 members found this post helpful.

It doesn't matter if it is in debug mode or not, it is still a problem in the kernel, not any other software.
Indeed, a really weird behavior, Greg Kroah-Hartman has already announced on the LKML that he will fix that, it will indeed be systemd.debug.

systemd is not relevant for kdbus.
kdbus != dbus.
AFAIK, most of kdbus is implemented GKH, but you are right, those patches have to be reviewed extensively, but for such an important part of a kernel as IPC I would recommend that anyway.
I don't hope so, having good IPC is really something the whole Linux ecosystem can benefit from. But only time can tell.

1 members found this post helpful.

fact remains that in 20 years no other program broke it
including the kernel itself

2 members found this post helpful.

If you're asking the kernel to do "X" inside core kernel functions, and then prevent it from doing so by having a userspace program running as root block access to resources needed to do "X", is the kernel wrong/broken for crashing? Anybody with root privileges can crash any kernel in seconds. That's by design, and certainly not a kernel bug.

There was a discussion (just finished) on the LKML about this, and one suggestion was to simply remove userspace access to /dev/kmsg altogether. After all, it's the kernel log; why should applications be able to write to it at all? It would have been a sensible move, and would have utterly broken the debug facility in systemd. (Not that it would have mattered, as it's obvious that the feature wasn't being used since neither Kay nor Lennart had noticed that it would crash the entire kernel.)

In defense of allowing userspace access to /dev/kmsg, Theodore Ts'o also pointed out that it was never supposed to be a syslog replacement, which I found hilarious since the program that caused this problem in the first place by abusing the hell out of /dev/kmsg IS intended to be a syslog replacement.

In the end they ended up rate-limiting /dev/kmsg, to prevent any program from flooding the log. I guess now the systemd team will claim it was a kernel issue all along. Linus expressed hopes this was all caused by incompetence, but others weren't entirely convinced.

3 members found this post helpful.

/dev/kmsg is supposed to act as log, even if it is not syslog, it shouldn't crash because it is logging. That it is the first time that a software crashes it by spamming doesn't matter, it still is a bug. I bet there are other bugs in the kernel that are not detected that are in a similar range of age, but that doesn't change the bug status.

Tobi if systemd is userland but is forcing a kernel crash through output generation, isn't that along the same lines as a major security flaw like a backdoor, memory leak, or other permission level elevation issue? Couldn't someone remote into a system and then use this parameter of systemd to bring down a system?

And BTW... sliced bread is not the best thing to have ever came along. Ethyl Alcohol is...

The problem was caused by systemd spamming the dmesg log when it detected the debug commandline option. If an attacker has access to the kernel commadline (read: your bootloader configuration) you have problems that are significantly worse than a crashing kernel. By the way, Greg Kroah-Hartmann considered the excessive amount of verbosity of systemd to be a bug and fixed that already.

Not that often that we agree on something, but this definitely is true.

Actually Tobi, you're getting it wrong..

Even the systemd guys know the debug is producing too much noise to be of any use, however they decide to keep it enabled in the global parameter 'debug' that one would use, well, guess what.. for actual debuging..

Even if they (the kernel devs) do put a rate limit to avoid possible system crashes, the fact remains that when a user/developer is trying to debug the kernel (which is the main function for 'debug') they would get a whole lot of noise they didn't ask for..

I get the ideea of putting the whole system initialization into debug mode, but when you know it's not useful and even creates problems and you still do it and expect others to clean behind you or just deal with it, then who's fault is it?

1 members found this post helpful.

To me, the kernel is like the engine in a car and the init system is like the gearbox, transferring the engine power into the drive train. If you drop in a new gearbox and the engine stalls when you select an unusual gear, then the problem is in the gearbox design.

12 members found this post helpful.

For something to be a bug, it has to (at the very least) involve a feature or function not working as intended.

I guess you could argue that the kernel "debug" feature wasn't working properly if the init system chose to deliberately block it, but you'll have to admit that's a pretty absurd corner case.

Also, it involves a process with root privileges using a kernel feature in a way it was never intended to be used. Since any privileged process can still cause a kernel panic by abusing any number of other kernel services, should we be filing lots of bug reports?

1 members found this post helpful.

Hey, see my other post about LKML April Fools Humor. Might be a good way to make a buck or so <GRIN>

I think this post by Linus is a great summary: http://lkml.iu.edu//hypermail/linux/...4.0/01488.html It's not that they are misusing a kernel feature, it's much simpler: their program causes systems to hang (for no good reason) when people are trying to debug Linux, so they should fix their program.

4 members found this post helpful.

http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

Remember Just For Fun?
RHT Community Fork 2.0, Just For Shareholder Value.

Here's the bugzilla at freedesktop.org. The bug history(open/close/open/close...) is entertaining.

https://bugs.freedesktop.org/show_bug.cgi?id=76935

1 members found this post helpful.

Yeah, it seems Kay only wants to avoid the issue entirely, not deal with it.

I hate to say it but Borislav and Mel are completely correct:

All the more reason I say, remove all support of udev from the Linux kernel, go back to DevFS, HAL, and Hotplug until Kay gets his head out of his or Lennart's arse.

2 members found this post helpful.