Diego Viola writes:
> Can't you just make a commit to fix it? If you want I can submit a patch.
>
> Sorry to be so OCD about this.
You know, I'd love to. If it were up to *me* I would. But my boss is a
stickler, y'know, and I've all filled my quota of useless makework for
the century. Hell, I
Can't you just make a commit to fix it? If you want I can submit a patch.
Sorry to be so OCD about this.
On Mon, May 19, 2014 at 10:26 PM, Rusty Russell wrote:
> Randy Dunlap writes:
>> On 05/19/2014 01:11 AM, Diego Viola wrote:
>>> I mean "e.g.:" is wrong, it should be e.g. or e.g.,
>>
>> I do
Randy Dunlap writes:
> On 05/19/2014 01:11 AM, Diego Viola wrote:
>> I mean "e.g.:" is wrong, it should be e.g. or e.g.,
>
> I don't see that in the wikipedia page. Are you basing that on
> "in this usage it is sometimes followed by a comma, depending on style."?
>
> I don't see a problem with th
On 05/19/2014 01:11 AM, Diego Viola wrote:
> I mean "e.g.:" is wrong, it should be e.g. or e.g.,
I don't see that in the wikipedia page. Are you basing that on
"in this usage it is sometimes followed by a comma, depending on style."?
I don't see a problem with the colon, since the quoted phrase
I mean "e.g.:" is wrong, it should be e.g. or e.g.,
Sorry to be too nitpicky or annoying about this.
Diego
On Mon, May 19, 2014 at 5:06 AM, Diego Viola wrote:
> e.g. should be written as e.g. or e.g.,
>
> There's no need to add another colon ":" after the one that it's already
> there.
>
> See
e.g. should be written as e.g. or e.g.,
There's no need to add another colon ":" after the one that it's already there.
See, http://en.wikipedia.org/wiki/E.g.#e.g.
Please fix that.
Thanks,
Diego
On Mon, May 5, 2014 at 9:57 PM, Rusty Russell wrote:
> Randy Dunlap writes:
>> All looks good to
On Thu, Apr 3, 2014 at 5:03 AM, Borislav Petkov wrote:
> On Thu, Apr 03, 2014 at 11:34:15AM +0100, Måns Rullgård wrote:
>> Once is an accident. Twice is incompetence. Three times is malice.
>
> Yeah, maybe it is time Linus started his own init daemon project, like
> that other thing, git, he did
On Sun, Apr 6, 2014 at 3:49 PM, David Timothy Strauss
wrote:
> On Fri, Apr 4, 2014 at 11:57 AM, Linus Torvalds
> wrote:
>> Since I haven't even heard a "my bad" from the systemd people, I'd be
>> inclined to say that a bit of protection for future issues would be a
>> good idea.
>
> Just coming b
On Thu, Apr 3, 2014 at 12:06 PM, Greg Kroah-Hartman
wrote:
> On Thu, Apr 03, 2014 at 08:17:33AM -0700, Tim Bird wrote:
>>
>> I had no idea systemd was so verbose and was abusing the kernel
>> log buffers so badly. I'm not a big fan of the rate-limiting, as this just
>> seems to encourage this kin
Randy Dunlap writes:
> All looks good to me except for 2 instances of "eg" which should be
> "e.g." (just above and about 4 paragraphs below here).
Thanks, fixed:
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 56a4c2d0c741..a42b9dd6b46b 100644
--- a
On 05/04/2014 07:17 PM, Rusty Russell wrote:
Andrew Morton writes:
On Mon, 07 Apr 2014 14:24:45 +0930 Rusty Russell wrote:
Subject: param: hand arguments after -- straight to init
The kernel passes any args it doesn't need through to init, except it
assumes anything containing '.' belongs t
Andrew Morton writes:
> On Mon, 07 Apr 2014 14:24:45 +0930 Rusty Russell
> wrote:
>
>> Subject: param: hand arguments after -- straight to init
>>
>> The kernel passes any args it doesn't need through to init, except it
>> assumes anything containing '.' belongs to the kernel (for a module).
>>
On Mon, 07 Apr 2014 14:24:45 +0930 Rusty Russell wrote:
> Subject: param: hand arguments after -- straight to init
>
> The kernel passes any args it doesn't need through to init, except it
> assumes anything containing '.' belongs to the kernel (for a module).
> This change means all users can c
On Wed, Apr 23, 2014 at 05:15:07PM +0200, Borislav Petkov wrote:
> Ok, here's a dirty hack that issues ratelimit messages at release
> time. I probably should wrap it nicely in ratelimit_*() accessors
> instead of poking directly at ratelimit_state. Yeah, maybe a
> ratelimit_exit() wrapper which do
Hi Linus,
here's some more massaging of your patch. (Btw, let's start a new
thread).
On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> It's definitely not perfect - if we suppress output, and the process
> then closes the file descriptor rather than continuing to write more,
> you
Hi Linus,
just checking on the status here: what did we decide on this one in
the end?
It works as expected, it is a good idea to have it as a protection
against every user space abuser, maybe we should apply it now that the
merge window is over and things are calming down?
Or should I remind yo
Linus Torvalds writes:
> On Wed, Apr 2, 2014 at 3:12 PM, Mateusz Guzik wrote:
>>
>> Well, parsing kernel cmdline by systemd is a bad idea
>
> No, we very much expose /proc/cmdline for a reason. System services
> are *supposed* to parse it, because it gives a unified way for people
> to pass in va
On Fri, Apr 4, 2014 at 11:57 AM, Linus Torvalds
wrote:
> Since I haven't even heard a "my bad" from the systemd people, I'd be
> inclined to say that a bit of protection for future issues would be a
> good idea.
Just coming back to this thread now, I'll say something. I'm a systemd
maintainer, an
On Thu, 3 Apr 2014 13:03:39 +0200
Borislav Petkov wrote:
> On Thu, Apr 03, 2014 at 11:34:15AM +0100, Måns Rullgård wrote:
> > Once is an accident. Twice is incompetence. Three times is malice.
>
> Yeah, maybe it is time Linus started his own init daemon project, like
> that other thing, git, h
On Fri, Apr 04, 2014 at 04:17:49PM -0700, Greg Kroah-Hartman wrote:
> > I think you mean "dmesg -T", and unfortunately it seems Debian 6.0.9
> > (or older) doesn ship a new enough linux-util since I've only got
> > 2.17.2-9 install.
>
> No, 'dmesg -H' is the right thing, you just need a modern v
> "Greg" == Greg Kroah-Hartman writes:
Greg> On Fri, Apr 04, 2014 at 05:17:09PM -0400, John Stoffel wrote:
>> > "Linus" == Linus Torvalds writes:
>>
Linus> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski
wrote:
>> >>
>> >> The other thing I've used /dev/kmsg for is to shove a "I'm s
On Fri, Apr 04, 2014 at 05:17:09PM -0400, John Stoffel wrote:
> > "Linus" == Linus Torvalds writes:
>
> Linus> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski
> wrote:
> >>
> >> The other thing I've used /dev/kmsg for is to shove a "I'm starting
> >> something now" message in. This is on
On Fri, Apr 4, 2014 at 1:17 PM, Theodore Ts'o wrote:
> On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote:
>> I saw one commenter say that this was a kernel bug because writing to
>> kmsg shouldn't cause the system to hang.
>>
>> The rate-limit patch would go along with that idea, and
On Fri, Apr 4, 2014 at 3:45 PM, Alexei Starovoitov
wrote:
>
> can there be two bulletproof buffers: one for in kernel printk
> and another ratelimited one for writes into /dev/kmsg.
> On the read from /dev/kmsg they're combined by time.
Or, you know, people could just stop spamming /dev/kmsg.
Le
> "Linus" == Linus Torvalds writes:
Linus> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski
wrote:
>>
>> The other thing I've used /dev/kmsg for is to shove a "I'm starting
>> something now" message in. This is only really necessary because the
>> current kernel log timestamps are unusabl
On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote:
> I saw one commenter say that this was a kernel bug because writing to
> kmsg shouldn't cause the system to hang.
>
> The rate-limit patch would go along with that idea, and I honestly
> think it would be good to rate-limit it in cas
On Fri, 4 Apr 2014 11:51:39 -0700
Andrew Morton wrote:
> On Fri, 4 Apr 2014 11:42:51 -0700 Linus Torvalds
> wrote:
>
> > Most users will never notice. The whole "writable /dev/kmsg" may go
> > back to 2002, but there aren't _that_ many users, and pretty much all
> > I've ever seen tend to writ
On Fri, Apr 4, 2014 at 11:57 AM, Andy Lutomirski wrote:
>
> What would break if we used CLOCK_BOOTTIME or CLOCK_MONOTONIC?
I wouldn't object to trying - I thought you meant changing the format
itself. If we keep the semantics (seconds since boot) but just change
the clock source in other ways, I
On Fri, Apr 4, 2014 at 11:42 AM, Linus Torvalds
wrote:
> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski wrote:
>>
>> I'm using /dev/kmsg in virtme so that I can easily capture, with
>> timestamps, the ten or so log lines that it produces. It would be sad
>> if I had to worry about small rateli
On Fri, Apr 4, 2014 at 11:32 AM, Linus Torvalds
wrote:
> On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski wrote:
>>
>> The other thing I've used /dev/kmsg for is to shove a "I'm starting
>> something now" message in. This is only really necessary because the
>> current kernel log timestamps are
On Fri, Apr 4, 2014 at 11:51 AM, Andrew Morton
wrote:
>
> Is there anything here that we really need to fix? What goes wrong if
> we leave kmsg as-is and systemd gets fixed?
Since I haven't even heard a "my bad" from the systemd people, I'd be
inclined to say that a bit of protection for future
On Fri, 4 Apr 2014 11:42:51 -0700 Linus Torvalds
wrote:
> Most users will never notice. The whole "writable /dev/kmsg" may go
> back to 2002, but there aren't _that_ many users, and pretty much all
> I've ever seen tend to write the occasional "I started up" messages or
> other very small notes.
On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski wrote:
>
> I'm using /dev/kmsg in virtme so that I can easily capture, with
> timestamps, the ten or so log lines that it produces. It would be sad
> if I had to worry about small ratelimits here.
So the _default_ rate limits (which is what my exa
On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski wrote:
>
> The other thing I've used /dev/kmsg for is to shove a "I'm starting
> something now" message in. This is only really necessary because the
> current kernel log timestamps are unusable crap. (We could fix that,
> hint hint.)
I'd actuall
On 04/03/2014 10:05 AM, Theodore Ts'o wrote:
> On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote:
>>
>> How about just ignoring writes to /dev/kmsg altogether by default
>> (unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
>> am missing something but what are the l
They will be in memory one way or another, and during boot memory is usually
plentiful to the kernel. Also, of the kernel knows it is log data it can be
dropped if needed.
On April 3, 2014 10:18:55 AM PDT, Theodore Ts'o wrote:
>On Thu, Apr 03, 2014 at 10:09:29AM -0700, H. Peter Anvin wrote:
>>
On Thu, Apr 03, 2014 at 08:17:33AM -0700, Tim Bird wrote:
>
> I had no idea systemd was so verbose and was abusing the kernel
> log buffers so badly. I'm not a big fan of the rate-limiting, as this just
> seems to encourage this kind of abuse.
That was a bug in systemd, and has been fixed up in
On Thu, Apr 03, 2014 at 10:09:29AM -0700, H. Peter Anvin wrote:
>
> Having the kernel be the keeper of the logging IPC isn't at all
> unreasonable. However, kmsg in its current form isn't adequate.
> Augmenting it into a proper logging IPC might be the right thing to do.
> (Hmm... new IPC... doe
On 04/03/2014 10:05 AM, Theodore Ts'o wrote:
>
> So there are so many other ways of solving this problem without trying
> to abuse the kernel logging facilities (which were never intended to
> be a general-purpose syslog replacement). I suspect some systemd
> developer was being lazy
>
Havi
On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote:
>
> How about just ignoring writes to /dev/kmsg altogether by default
> (unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
> am missing something but what are the legitimate use-cases for generally
> allowing user-
On Thu, Apr 3, 2014 at 4:25 AM, Måns Rullgård wrote:
> Jiri Kosina writes:
>
>> On Wed, 2 Apr 2014, Linus Torvalds wrote:
>>
>>> Steven, Borislav, one thing that strikes me might be a good idea is to
>>> limit the amount of non-kernel noise in dmesg. We already have the
>>> concept of rate-limiti
* Borislav Petkov wrote:
> On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> > Whether it actually fixes the problem that Borislav had is
> > questionable, of course. For all I know, systemd debug mode generates
> > so much data in *other* ways and then causes feedback loops with
Jiri Kosina writes:
> On Wed, 2 Apr 2014, Linus Torvalds wrote:
>
>> Steven, Borislav, one thing that strikes me might be a good idea is to
>> limit the amount of non-kernel noise in dmesg. We already have the
>> concept of rate-limiting various spammy internal kernel messages for
>> when devi
On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Whether it actually fixes the problem that Borislav had is
> questionable, of course. For all I know, systemd debug mode generates
> so much data in *other* ways and then causes feedback loops with
> the kernel debugging that this pa
On Thu, Apr 03, 2014 at 11:34:15AM +0100, Måns Rullgård wrote:
> Once is an accident. Twice is incompetence. Three times is malice.
Yeah, maybe it is time Linus started his own init daemon project, like
that other thing, git, he did start a while ago. We can put it in
tools/. I'm sure it can get
On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Whether it actually fixes the problem that Borislav had is
> questionable, of course. For all I know, systemd debug mode generates
> so much data in *other* ways and then causes feedback loops with the
> kernel debugging that this pa
Linus Torvalds writes:
> On Wed, Apr 2, 2014 at 4:47 PM, Jiri Kosina wrote:
>>
>> Which doesn't really protect you from tasks that do open()/write()/close()
>> cycle for /dev/kmsg write every 2ms though.
>
> I don't think we should try to protect against wilful bad behavior
> unless that is show
On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Borislav?
We're trying to reproduce the original issue with the assertion firing
and drowning dmesg but it is a huuge box and a bit flaky so it'll take
some time.
I'll let you know as soon as I have something.
Thanks.
--
Regards
On Wed, Apr 2, 2014 at 4:52 PM, Linus Torvalds
wrote:
>
> TOTALLY UNTESTED. But it really isn't complex.
Oh, and here's a patch that is actually lightly tested. I did
while :; do echo hello; done > /dev/kmsg
(the 'yes' program buffers output, so won't work) and I get
[ 122.062912] hel
On Wed, 2 Apr 2014 16:52:59 -0700
Linus Torvalds wrote:
> On Wed, Apr 2, 2014 at 4:47 PM, Jiri Kosina wrote:
> >
> > Which doesn't really protect you from tasks that do open()/write()/close()
> > cycle for /dev/kmsg write every 2ms though.
>
> I don't think we should try to protect against wilf
On Thu, 3 Apr 2014 00:12:13 +0200
Mateusz Guzik wrote:
> Well, parsing kernel cmdline by systemd is a bad idea, and hiding
> "debug" is even worse. What will happen when the next keyword clashes?
> And how should I check the kernel is booted with "debug"?
No, I think you got it backwards. Hidi
On Wed, 2 Apr 2014, Linus Torvalds wrote:
> > Which doesn't really protect you from tasks that do open()/write()/close()
> > cycle for /dev/kmsg write every 2ms though.
>
> I don't think we should try to protect against wilful bad behavior
> unless that is shown to be necessary. Yeah, if it turns
On Wed, Apr 2, 2014 at 4:47 PM, Jiri Kosina wrote:
>
> Which doesn't really protect you from tasks that do open()/write()/close()
> cycle for /dev/kmsg write every 2ms though.
I don't think we should try to protect against wilful bad behavior
unless that is shown to be necessary. Yeah, if it turn
On Wed, 2014-04-02 at 16:42 -0700, Linus Torvalds wrote:
> On Wed, Apr 2, 2014 at 4:28 PM, Andrew Morton
> wrote:
> >
> > Could be done per-fd: put a struct ratelimit_state into struct
> > devkmsg_user.
>
> Yeah, what Andrew said.
The default ratelimit state values are pretty low
and may need t
On Wed, 2 Apr 2014, Linus Torvalds wrote:
> > Could be done per-fd: put a struct ratelimit_state into struct
> > devkmsg_user.
>
> Yeah, what Andrew said. My suggestion of per-task or per-cred is
> obviously moronic in comparison.
Which doesn't really protect you from tasks that do open()/write(
On Wed, Apr 2, 2014 at 4:28 PM, Andrew Morton wrote:
>
> Could be done per-fd: put a struct ratelimit_state into struct
> devkmsg_user.
Yeah, what Andrew said. My suggestion of per-task or per-cred is
obviously moronic in comparison.
Linus "hangs head in shame" Torvalds
--
To uns
On Wed, Apr 2, 2014 at 4:23 PM, Jiri Kosina wrote:
>
> I think that it's in principle a good idea, however ... the in-kernel
> ratelimiting always happens per sourcecode location, but this will be
> rather hard to achieve with interface such as /dev/kmsg.
>
> If /dev/kmsg is going to be ratelimite
On Thu, 3 Apr 2014 01:23:15 +0200 (CEST) Jiri Kosina wrote:
> On Wed, 2 Apr 2014, Linus Torvalds wrote:
>
> > Steven, Borislav, one thing that strikes me might be a good idea is to
> > limit the amount of non-kernel noise in dmesg. We already have the
> > concept of rate-limiting various spamm
On Wed, 2 Apr 2014, Linus Torvalds wrote:
> Steven, Borislav, one thing that strikes me might be a good idea is to
> limit the amount of non-kernel noise in dmesg. We already have the
> concept of rate-limiting various spammy internal kernel messages for
> when device drivers misbehave etc. May
On Wed, Apr 2, 2014 at 3:12 PM, Mateusz Guzik wrote:
>
> Well, parsing kernel cmdline by systemd is a bad idea
No, we very much expose /proc/cmdline for a reason. System services
are *supposed* to parse it, because it gives a unified way for people
to pass in various flags. The kernel doesn't com
On Thu, Apr 03, 2014 at 12:12:13AM +0200, Mateusz Guzik wrote:
> On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happen
On 04/02/2014 03:12 PM, Mateusz Guzik wrote:
On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool
On Wed, Apr 02, 2014 at 12:04:40PM -0700, Andrew Morton wrote:
> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happens is
On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
> It has come to our attention that a system running a specific user
> space init program will not boot if you add "debug" to the kernel
> command line. What happens is that the user space tool parses the
> kernel command line, and if
On Wed, 2 Apr 2014, Richard Weinberger wrote:
> While we are here, can we please also talk about the !cgroup situation?
> https://bugs.freedesktop.org/show_bug.cgi?id=74589
>
> A segfaulting systemd on CONFIG_CGROUPS=n is no fun.
Wow, the attitude there is amazing:
"To make this work we'd need a
On Wed, Apr 2, 2014 at 9:50 PM, Thomas Gleixner wrote:
> On Wed, 2 Apr 2014, Andrew Morton wrote:
>> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>>
>> > It has come to our attention that a system running a specific user
>> > space init program will not boot if you add "debug" to the k
On Wed, 2 Apr 2014, Andrew Morton wrote:
> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happens is that the user space t
On Wed, 2 Apr 2014 21:08:51 +0200
Borislav Petkov wrote:
> Well, maybe the minor nit that it leaves two spaces in /proc/cmdline now:
>
> "root=/dev/sda1 ignore_loglevel log_buf_len=10M earlyprintk=ttyS0,115200
> console=ttyS0,115200 console=tty0"
>
> Also, you need to add
>
> Suggested-by:
On Wed, Apr 02, 2014 at 02:42:19PM -0400, Steven Rostedt wrote:
> It has come to our attention that a system running a specific user
> space init program will not boot if you add "debug" to the kernel
> command line. What happens is that the user space tool parses the
> kernel command line, and if
On 04/02/2014 12:04 PM, Andrew Morton wrote:
On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parse
On Wed, Apr 02, 2014 at 12:04:40PM -0700, Andrew Morton wrote:
> On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
>
> > It has come to our attention that a system running a specific user
> > space init program will not boot if you add "debug" to the kernel
> > command line. What happens is
On Wed, 2 Apr 2014 14:42:19 -0400 Steven Rostedt wrote:
> It has come to our attention that a system running a specific user
> space init program will not boot if you add "debug" to the kernel
> command line. What happens is that the user space tool parses the
> kernel command line, and if it see
On Wed, Apr 2, 2014 at 11:42 AM, Steven Rostedt wrote:
>
> The response is:
>
> "Generic terms are generic, not the first user owns them."
And by "their" you mean Kay Sievers.
Key, I'm f*cking tired of the fact that you don't fix problems in the
code *you* write, so that the kernel then has to w
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line. What happens is that the user space tool parses the
kernel command line, and if it sees "debug" it will spit out so much
information that the system fai
74 matches
Mail list logo
