LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 04-03-2014, 04:32 PM   #16
Drakeo
Senior Member
 
Registered: Jan 2008
Location: Urbana IL
Distribution: Slackware, Slacko,
Posts: 2,658
Blog Entries: 3

Rep: Reputation: 224Reputation: 224Reputation: 224

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.
Old 04-03-2014, 04:38 PM   #17
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by Ser Olmy View Post
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.
 
1 members found this post helpful.
Old 04-03-2014, 05:39 PM   #18
genss
Member
 
Registered: Nov 2013
Posts: 361

Rep: Reputation: Disabled
Quote:
Originally Posted by TobiSGD View Post
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
 
1 members found this post helpful.
Old 04-03-2014, 05:45 PM   #19
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,114

Rep: Reputation: Disabled
Quote:
Originally Posted by TobiSGD View Post
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.
 
2 members found this post helpful.
Old 04-03-2014, 07:50 PM   #20
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
/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.
 
Old 04-03-2014, 07:56 PM   #21
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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...
 
Old 04-03-2014, 08:28 PM   #22
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by ReaperX7 View Post
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.
 
Old 04-04-2014, 07:11 AM   #23
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 400

Rep: Reputation: 113Reputation: 113
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.
Old 04-04-2014, 07:39 AM   #24
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 3,520

Rep: Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873
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.
 
11 members found this post helpful.
Old 04-04-2014, 09:47 AM   #25
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 2,114

Rep: Reputation: Disabled
Quote:
Originally Posted by TobiSGD View Post
/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?
 
1 members found this post helpful.
Old 04-04-2014, 10:54 AM   #26
Spect73
Member
 
Registered: Aug 2013
Distribution: Slackware 14.1
Posts: 128

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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>
 
Old 04-04-2014, 11:30 AM   #27
qweasd
Member
 
Registered: May 2010
Posts: 484

Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
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.
 
4 members found this post helpful.
Old 04-04-2014, 03:20 PM   #28
EYo
Member
 
Registered: Jun 2009
Location: Cloverdale
Distribution: Slackware
Posts: 99

Rep: Reputation: 56
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.
 
Old 04-04-2014, 04:32 PM   #29
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: CentOS 6 (pre-systemd)
Posts: 1,773

Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
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.
Old 04-04-2014, 10:19 PM   #30
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,834
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Linus on Linux: The Linus Torvalds Interview Part 2 LXer Syndicated Linux News 0 04-27-2009 02:00 PM
LXer: Linus on Linux: The Linus Torvalds Interview Part 1 LXer Syndicated Linux News 0 04-23-2009 04:10 PM
Linus Torvalds rakris General 1 11-14-2006 03:07 AM
Linus Torvalds divorce3 General 8 02-10-2005 02:34 AM
Linus Torvalds linuxzouk General 7 05-16-2004 11:17 PM


All times are GMT -5. The time now is 04:48 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration