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
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Quote:
including the kernel itself |
Quote:
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. |
/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... ;) |
Quote:
Quote:
|
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? |
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.
|
Quote:
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? |
Quote:
|
Quote:
|
Thank you Linus!
Quote:
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 |
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: Quote:
Quote:
|
All times are GMT -5. The time now is 09:42 AM. |