LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Linus Torvalds vs Kay Sievers (https://www.linuxquestions.org/questions/slackware-14/linus-torvalds-vs-kay-sievers-4175500369/)

Drakeo 04-03-2014 03:32 PM

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

TobiSGD 04-03-2014 03:38 PM

Quote:

Originally Posted by Ser Olmy (Post 5146126)
Remember, this only occurs when the kernel is given the "debug" parameter. Debug mode is not a normal operating condition for the kernel by any stretch of the imagination, and may indeed create an unusual dependency with the tty layer. That's basically what it's supposed to do.

It doesn't matter if it is in debug mode or not, it is still a problem in the kernel, not any other software.
Quote:

I put the blame squarely on the systemd developers for failing to distinguish between "debug" and, say, "systemd.debug". Everybody else seems perfectly capable of doing just that, as even a cursory glance at the kernel documentaion will show.
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.

Quote:

Even if systemd was perfect
systemd is not relevant for kdbus.
Quote:

dbus was the best thing since sliced bread
kdbus != dbus.
Quote:

it would be a mistake to trust such a grossly mismanaged project with providing important functionality to Linux in general.
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.
Quote:

Add to that the undeniable fact that the two senior (I'm using the term in the most loosely possible manner) developers are unwilling to listen to any viewpoint that conflicts with their own, and are demonstrably reluctant to fix their own crash bugs, and you get a perfect storm. This isn't going to end well.
I don't hope so, having good IPC is really something the whole Linux ecosystem can benefit from. But only time can tell.

genss 04-03-2014 04:39 PM

Quote:

Originally Posted by TobiSGD (Post 5146134)
It doesn't matter if it is in debug mode or not, it is still a problem in the kernel, not any other software.

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

Ser Olmy 04-03-2014 04:45 PM

Quote:

Originally Posted by TobiSGD (Post 5146134)
It doesn't matter if it is in debug mode or not, it is still a problem in the kernel, not any other software.

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.

TobiSGD 04-03-2014 06:50 PM

/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.

ReaperX7 04-03-2014 06:56 PM

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... ;)

TobiSGD 04-03-2014 07:28 PM

Quote:

Originally Posted by ReaperX7 (Post 5146218)
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?

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.

Quote:

And BTW... sliced bread is not the best thing to have ever came along. Ethyl Alcohol is...
Not that often that we agree on something, but this definitely is true.

Smokey_justme 04-04-2014 06:11 AM

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?

allend 04-04-2014 06:39 AM

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.

Ser Olmy 04-04-2014 08:47 AM

Quote:

Originally Posted by TobiSGD (Post 5146215)
/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.

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?

Spect73 04-04-2014 09:54 AM

Quote:

Originally Posted by Ser Olmy (Post 5146548)
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?

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

qweasd 04-04-2014 10:30 AM

Quote:

Originally Posted by Ser Olmy (Post 5146548)
Also, it involves a process with root privileges using a kernel feature in a way it was never intended to be used.

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.

EYo 04-04-2014 02:20 PM

Thank you Linus!
 
Quote:

It looks like Greg has stepped in as a baby-sitter for Kay, and things
are going to be fixed. And I'd really like to avoid adding hacky code
to the kernel because of Kay's continued bad behavior, so I hope this
works. But it's really sad that things like this get elevated to this
kind of situation, and I personally find it annoying that it's always
the same f*cking primadonna involved.
http://lkml.iu.edu//hypermail/linux/...4.0/01488.html

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

smallpond 04-04-2014 03:32 PM

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

ReaperX7 04-04-2014 09:19 PM

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:

Originally Posted by Mel Gorman
> Bugzilla is not a discussion forum, and repeating the same

Ok, the bug is that a *kernel* parameter compels a *userspace* program to trash the *kernels* log with enough information to break boot due to timeouts.

Quote:

Originally Posted by Borislav Petkov
> Again, move discussions to the mailing list; this is a bug tracker,
> but there is no bug to track or fix here.

Dude, are you for real? Are you actually actively trying to be a d*ck or
you're this way by default. We're telling you there's a serious issue
and we're even being constructive by giving suggestions and you're
deflecting.

You have got to be f*cking kidding me!

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.


All times are GMT -5. The time now is 09:42 AM.