On (09/17/17 20:07), Joe Perches wrote:
> On Mon, 2017-09-18 at 11:55 +0900, Sergey Senozhatsky wrote:
> > Try git grep KERN_SOH.
> >
> > what for?
>
> Did you read your own email?
>
> > printk(KERN_SOH_ASCII %d " foo bar / %s %s\n", "foo", "bar");
>
> _nothing_ looks like that.
OK... got
On Mon, 2017-09-18 at 11:55 +0900, Sergey Senozhatsky wrote:
> Try git grep KERN_SOH.
>
> what for?
Did you read your own email?
> printk(KERN_SOH_ASCII %d " foo bar / %s %s\n", "foo", "bar");
_nothing_ looks like that.
It wouldn't even compile.
On (09/17/17 19:45), Joe Perches wrote:
[..]
> > take a look at ACPI acpi_os_vprintf(). for instance.
>
> I've looked.
I don't get your point.
#define ACPI_MSG_ERROR KERN_ERR "ACPI Error: "
#define ACPI_MSG_EXCEPTION KERN_ERR "ACPI Exception: "
#define ACPI_MSG_WARNINGKERN_
On Mon, 2017-09-18 at 11:41 +0900, Sergey Senozhatsky wrote:
> On (09/17/17 19:22), Joe Perches wrote:
> > On Mon, 2017-09-18 at 09:46 +0900, Sergey Senozhatsky wrote:
> > > there is another reason why I think that, yes, we probably better do
> > > it some other way. and the reason is that not ever
On (09/17/17 19:22), Joe Perches wrote:
> On Mon, 2017-09-18 at 09:46 +0900, Sergey Senozhatsky wrote:
> > there is another reason why I think that, yes, we probably better do
> > it some other way. and the reason is that not every message that looks
> > like !PREFIX (does not start with KERN_SOH_A
On Mon, 2017-09-18 at 09:46 +0900, Sergey Senozhatsky wrote:
> there is another reason why I think that, yes, we probably better do
> it some other way. and the reason is that not every message that looks
> like !PREFIX (does not start with KERN_SOH_ASCII) is _actually_ a
> !PREFIX message. the nor
Hello Linus,
On (09/17/17 08:35), Linus Torvalds wrote:
> On Sat, Sep 16, 2017 at 11:26 PM, Sergey Senozhatsky
> wrote:
> >
> > so... I think we don't have to update 'struct printk_log'. we can store
> > that "extended data" at the beginning of every message, right after the
> > prefix.
>
> No,
On Sat, Sep 16, 2017 at 11:26 PM, Sergey Senozhatsky
wrote:
>
> so... I think we don't have to update 'struct printk_log'. we can store
> that "extended data" at the beginning of every message, right after the
> prefix.
No, we really can't. That just means that all the tools would have to
be chan
On (09/17/17 15:26), Sergey Senozhatsky wrote:
[..]
> > Anyway, it seems that we will need to update all the tools
> > for the different time stamps, see
> > https://lkml.kernel.org/r/1504613201-23868-1-git-send-email-pra...@redhat.com
> > Then we will be more clever how painful it is.
may be we c
On (09/06/17 09:55), Petr Mladek wrote:
[..]
> > but I'm not super eager to have printk-safe based buffering.
> > that's why I never posted a patch set. this approach has its
> > limitations.
>
> Ah, I am happy to read this. From the previous mails,
> I got the feeling that you were eager to go th
On Wed 2017-08-30 14:37:34, Sergey Senozhatsky wrote:
> On (08/29/17 19:58), Joe Perches wrote:
> > > >
> > > > Why?
> > > >
> > > > What's wrong with a simple printk?
> > > > It'd still do a log_store.
> > >
> > > sure, it will. but in separate logbuf entries, and between two
> > > consequent p
On Tue 2017-09-05 22:42:28, Sergey Senozhatsky wrote:
> On (09/05/17 14:21), Petr Mladek wrote:
> [..]
> > > that's why I want buffered printk to re-use the printk-safe buffer
> > > on that particular CPU [ if buffered printk will ever land ].
> > > printk-safe buffer is not allocated on stack, or
On Tue, Sep 5, 2017 at 7:54 AM, Steven Rostedt wrote:
> You can do what I did with trace_printk(). I have a buffer per context.
> Then you only need to use preempt_disable() to do the print. That is,
> trace_printk() has 4 buffers:
>
> 1. Normal context
> 2. softirq context
> 3. irq context
>
On (09/05/17 10:54), Steven Rostedt wrote:
> On Mon, 4 Sep 2017 14:22:46 +0900
> Sergey Senozhatsky wrote:
>
> > like I said in another email, printk-safe buffer
> > is per-CPU and is also used for actual printk-safe, hence it must be
> > used with local IRQs disabled when we "borrow" the buffer
On Mon, 4 Sep 2017 14:22:46 +0900
Sergey Senozhatsky wrote:
> like I said in another email, printk-safe buffer
> is per-CPU and is also used for actual printk-safe, hence it must be
> used with local IRQs disabled when we "borrow" the buffer for pr_line
> (disabled preemption is not enough due to
On (09/05/17 21:35), Tetsuo Handa wrote:
[..]
> > Well, what do you think about the extra printed information?
> > For example:
> >
> >message
> >
> > It looks straightforward to me. These information
> > might be helpful on its own. So, it might be a
> > win-win solution.
>
> Yes, if bu
On (09/05/17 14:21), Petr Mladek wrote:
[..]
> > that's why I want buffered printk to re-use the printk-safe buffer
> > on that particular CPU [ if buffered printk will ever land ].
> > printk-safe buffer is not allocated on stack, or kmalloc-ed for
> > temp usafe, and, more importantly, we flush i
Petr Mladek wrote:
> Some of these problems would be solved by a custom buffer.
> But you are right. There are less guarantees that it would
> get flushed or that it can be found in case of troubles.
> Now, I am not sure that it is a good idea to use it even
> for a single continuous line.
>
> I w
On Tue 2017-09-05 18:59:00, Sergey Senozhatsky wrote:
> On (09/05/17 11:44), Petr Mladek wrote:
> [..]
> > > Tetsuo wants this, for instance,
> > > for OOM reports and backtraces. SCIS/ATA people want it as well.
> >
> > The mixing of related lines might cause problems. But I am not sure
> > if it
On (09/05/17 11:44), Petr Mladek wrote:
[..]
> > Tetsuo wants this, for instance,
> > for OOM reports and backtraces. SCIS/ATA people want it as well.
>
> The mixing of related lines might cause problems. But I am not sure
> if it can be fixed a safe way on the printk side. Especially I am
> afrai
On Wed 2017-08-30 11:47:03, Sergey Senozhatsky wrote:
> On (08/29/17 19:31), Joe Perches wrote:
> [..]
> > > the idea is not to do printk() on that seq buffer at all, but to
> > > log_store(), atomically, seq buffer messages
> > >
> > > spin_lock(&logbuf_lock)
> > > while (offset < seq_buffer-
On Mon, 2017-09-04 at 14:22 +0900, Sergey Senozhatsky wrote:
> there is only way to serialize printks against other printks -- take
> the logbuf lock.
If that's really necessary, instead make that
logbuf_lock a public interface and keep the rest
of the code simple.
I think it's more important to
On (09/04/17 13:30), Sergey Senozhatsky wrote:
> On (09/01/17 10:32), Joe Perches wrote:
> [..]
> > > +static inlin __printf(2, 3) __cold
> >
> > uncompiled
> >
> > > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...)
> >
> > inline
> >
>
> thanks.
>
> there is always a missin
Hello,
I'll answer to both Linus and Joe, just to keep it all one place.
On (09/01/17 13:21), Linus Torvalds wrote:
> On Fri, Sep 1, 2017 at 10:32 AM, Joe Perches wrote:
> >
> > Yes, it's a poor name. At least keep using a pr_ prefix.
>
> I'd suggest perhaps just "pr_line()".
ok, pr_line soun
On (09/01/17 10:32), Joe Perches wrote:
[..]
> > +static inlin __printf(2, 3) __cold
>
> uncompiled
>
> > +static int __prbuf_write(struct seq_buf *s, const char *fmt, ...)
>
> inline
>
thanks.
there is always a missing
if (console_trylock())
console_unlock();
in flu
On Fri, Sep 1, 2017 at 11:12 PM, Tetsuo Handa
wrote:
>
> I just tried to distinguish context using one "unsigned long" value
> by embedding IRQ status into lower bits of "struct task_struct *".
> I can change to distinguish context using multiple "unsigned long" values.
I really really don't thin
Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 1:41 PM, Tetsuo Handa
> wrote:
> >>
> >> A private buffer has none of those issues.
> >
> > Yes, I posted "[PATCH] printk: Add best-effort printk() buffering." at
> > http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-ker...@i-love.sak
On Fri, Sep 1, 2017 at 10:32 AM, Joe Perches wrote:
>
> Yes, it's a poor name. At least keep using a pr_ prefix.
I'd suggest perhaps just "pr_line()".
And instead of having those "err/info/cont" variations, the severity
level should just be set at initialization time. Not different
versions of
On Fri, 2017-09-01 at 22:19 +0900, Sergey Senozhatsky wrote:
> On (08/29/17 21:10), Steven Rostedt wrote:
> [..]
> > > could do. for a single continuation line printk("%.*s", s.len, s.buffer)
> > > this will work perfectly fine. for a more general case - backtraces,
> > > dumps,
> > > etc. - this
On (08/29/17 21:10), Steven Rostedt wrote:
[..]
> > could do. for a single continuation line printk("%.*s", s.len, s.buffer)
> > this will work perfectly fine. for a more general case - backtraces, dumps,
> > etc. - this requires some tweaks.
>
> We could simply add a seq_buf_printk() that is impl
On Fri, 1 Sep 2017 09:29:06 +0200
Pavel Machek wrote:
> Well, usually dev_info (and friends) is right thing to use for
> production. But very little debugging remains after the
> .. well.. debugging phase, so something that behaves similar to
> printf() is nice.
Try using trace_printk(). Who us
On Fri 2017-09-01 10:40:12, Sergey Senozhatsky wrote:
> Hi,
>
> On (08/29/17 22:24), Pavel Machek wrote:
> > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > there? Are timestamps responsible?
> > >
> >
On Fri, 2017-09-01 at 08:59 +0200, Pavel Machek wrote:
> On Thu 2017-08-31 19:04:24, Joe Perches wrote:
> > On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> > > On (08/29/17 22:24), Pavel Machek wrote:
> > > > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > > >
On Thu 2017-08-31 19:04:24, Joe Perches wrote:
> On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> > On (08/29/17 22:24), Pavel Machek wrote:
> > > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
On Fri, 2017-09-01 at 10:40 +0900, Sergey Senozhatsky wrote:
> On (08/29/17 22:24), Pavel Machek wrote:
> > > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > > there? Are timestamps responsible?
[]
> > You a
Hi,
On (08/29/17 22:24), Pavel Machek wrote:
> > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > > there? Are timestamps responsible?
> >
> > No.
> >
> > It's actively trying to treach you not to do shit.
> >
On (08/29/17 19:58), Joe Perches wrote:
> > >
> > > Why?
> > >
> > > What's wrong with a simple printk?
> > > It'd still do a log_store.
> >
> > sure, it will. but in separate logbuf entries, and between two
> > consequent printk calls on the same CPU a lot of stuff can happen:
>
> I think you
On Wed, 2017-08-30 at 11:47 +0900, Sergey Senozhatsky wrote:
> On (08/29/17 19:31), Joe Perches wrote:
> [..]
> > > the idea is not to do printk() on that seq buffer at all, but to
> > > log_store(), atomically, seq buffer messages
> > >
> > > spin_lock(&logbuf_lock)
> > > while (offset < seq_
On (08/29/17 19:31), Joe Perches wrote:
[..]
> > the idea is not to do printk() on that seq buffer at all, but to
> > log_store(), atomically, seq buffer messages
> >
> > spin_lock(&logbuf_lock)
> > while (offset < seq_buffer->len) {
> > ...
> > log_store(seq->buffe
On Wed, 2017-08-30 at 11:25 +0900, Sergey Senozhatsky wrote:
> On (08/29/17 18:52), Joe Perches wrote:
> [..]
> > > We could simply add a seq_buf_printk() that is implemented in the printk
> > > proper, to parse the seq_buf buffer properly, and add the timestamps and
> > > such.
> >
> > No need.
On (08/29/17 18:52), Joe Perches wrote:
[..]
> > We could simply add a seq_buf_printk() that is implemented in the printk
> > proper, to parse the seq_buf buffer properly, and add the timestamps and
> > such.
>
> No need. printk would already add timestamps.
the idea is not to do printk() on tha
On Tue, 2017-08-29 at 21:10 -0400, Steven Rostedt wrote:
> On Wed, 30 Aug 2017 10:03:48 +0900
> Sergey Senozhatsky wrote:
>
> > Hello,
> >
> > On (08/29/17 19:50), Steven Rostedt wrote:
> > [..]
> > > > A private buffer has none of those issues.
> > >
> > > What about using the seq_buf*() the
On (08/29/17 21:10), Steven Rostedt wrote:
> > On (08/29/17 19:50), Steven Rostedt wrote:
> > [..]
> > > > A private buffer has none of those issues.
> > >
> > > What about using the seq_buf*() then?
> > >
> > > struct seq_buf s;
> > >
> > > buf = kmalloc(mysize);
> > > seq_buf_init(&s,
On Wed, 30 Aug 2017 10:03:48 +0900
Sergey Senozhatsky wrote:
> Hello,
>
> On (08/29/17 19:50), Steven Rostedt wrote:
> [..]
> > > A private buffer has none of those issues.
> >
> > What about using the seq_buf*() then?
> >
> > struct seq_buf s;
> >
> > buf = kmalloc(mysize);
> >
On (08/29/17 11:09), Joe Perches wrote:
[..]
> > Introduce a few helper functions for it:
> >
> > init_line_buffer(&buf);
> > print_line(&buf, fmt, args);
> > vprint_line(&buf, fmt, vararg);
> > finish_line(&buf);
> >
> > or whatever, and it sounds like it should be pretty easy to use.
>
> M
Hello,
On (08/29/17 19:50), Steven Rostedt wrote:
[..]
> > A private buffer has none of those issues.
>
> What about using the seq_buf*() then?
>
> struct seq_buf s;
>
> buf = kmalloc(mysize);
> seq_buf_init(&s, buf, mysize);
>
> seq_printf(&s,"blah blah %d", bah_blah);
Hello,
On (08/29/17 10:52), Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
> wrote:
> >
> > ok. that's something several people asked for -- some sort of buffered
> > printk mode; but people don't want to use a buffer allocated on the stack
> > (or kmalloc-ed, etc.)
On Tue, Aug 29, 2017 at 4:50 PM, Steven Rostedt wrote:
>
> What about using the seq_buf*() then?
They do have the nice property that because we use them for various
/proc files, there are some helper functions in addition to just the
puts/printt/vprintf.
Ie seq_buf_putmem_hex().
And yeah, you c
On Tue, 29 Aug 2017 10:12:22 -0700
Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:00 AM, Linus Torvalds
> wrote:
> >
> > I refuse to help those things. We mis-designed things
>
> Actually, let me rephrase that:
>
> It might actually be a good idea to help those things, by making
> helper
On Tue, Aug 29, 2017 at 1:41 PM, Tetsuo Handa
wrote:
>>
>> A private buffer has none of those issues.
>
> Yes, I posted "[PATCH] printk: Add best-effort printk() buffering." at
> http://lkml.kernel.org/r/1493560477-3016-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp
> .
No, this is exactly
Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:00 AM, Linus Torvalds
> wrote:
> >
> > I refuse to help those things. We mis-designed things
>
> Actually, let me rephrase that:
>
> It might actually be a good idea to help those things, by making
> helper functions available that do the marsha
Hi!
> > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > there? Are timestamps responsible?
>
> No.
>
> It's actively trying to treach you not to do shit.
>
> If you want to continue a line, you NEED to use KERN_
On Tue, 2017-08-29 at 10:52 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
> wrote:
> >
> > ok. that's something several people asked for -- some sort of buffered
> > printk mode; but people don't want to use a buffer allocated on the stack
> > (or kmalloc-ed,
On Tue, Aug 29, 2017 at 10:33 AM, Sergey Senozhatsky
wrote:
>
> ok. that's something several people asked for -- some sort of buffered
> printk mode; but people don't want to use a buffer allocated on the stack
> (or kmalloc-ed, etc.) to do sprintf() on it and then feed it to printk("%s"),
> becau
On Tue, 2017-08-29 at 10:36 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:33 AM, Joe Perches wrote:
> >
> > Your change broke a bunch of output.
>
> Tough. We've done that before to force people to fix their code.
No worries.
I don't mind the change at all really.
You do seem to li
Hello,
On (08/29/17 10:00), Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 6:40 AM, Sergey Senozhatsky
> wrote:
> > Pavel reported that
> > printk("foo"); printk("bar");
> >
> > now does not produce a single continuation "foobar" line, but
> > instead produces two lines
> >
On Tue, Aug 29, 2017 at 10:33 AM, Joe Perches wrote:
>
> Your change broke a bunch of output.
Tough. We've done that before to force people to fix their code.
I'm actually upset that EVEN NOW (and it's been, what, 18 months),
people ask for the old broken shit behavior back.
It's ten years sinc
On Tue, 2017-08-29 at 10:20 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:10 AM, Joe Perches wrote:
> > That's simply false.
> >
> > It was never true until you made it a requirement.
> > (it's not a bad requirement, but it did change behavior)
>
> Oh, it changed behavior, yes (and f
On Tue, Aug 29, 2017 at 10:10 AM, Joe Perches wrote:
> That's simply false.
>
> It was never true until you made it a requirement.
> (it's not a bad requirement, but it did change behavior)
Oh, it changed behavior, yes (and for kernel code we do that, and
require people to change).
But even befo
On Tue, Aug 29, 2017 at 10:00 AM, Linus Torvalds
wrote:
>
> I refuse to help those things. We mis-designed things
Actually, let me rephrase that:
It might actually be a good idea to help those things, by making
helper functions available that do the marshalling.
So not calling "printk()" direct
On Tue, 2017-08-29 at 09:48 -0700, Linus Torvalds wrote:
> On Mon, Aug 28, 2017 at 2:05 AM, Pavel Machek wrote:
> > Hi!
> >
> > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > there? Are timestamps responsible?
>
On Tue, Aug 29, 2017 at 6:40 AM, Sergey Senozhatsky
wrote:
> Pavel reported that
> printk("foo"); printk("bar");
>
> now does not produce a single continuation "foobar" line, but
> instead produces two lines
> foo
> bar
And that's the *correct* behavior.
S
On Mon, Aug 28, 2017 at 2:05 AM, Pavel Machek wrote:
> Hi!
>
> In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> foo\nbar. That's... quite surprising/unwelcome. What is going on
> there? Are timestamps responsible?
No.
It's actively trying to treach you not to do shit.
If you want to
On Tue, 2017-08-29 at 22:40 +0900, Sergey Senozhatsky wrote:
> Hi,
>
> so I had a second look, and I think the patch I posted yesterday is
> pretty wrong. How about something like below?
> ---
>
> From d65d1b74d3acc51e5d998c5d2cf10d20c28dc2f9 Mon Sep 17 00:00:00 2001
> From: Sergey Senozhatsky
Hi,
so I had a second look, and I think the patch I posted yesterday is
pretty wrong. How about something like below?
---
>From d65d1b74d3acc51e5d998c5d2cf10d20c28dc2f9 Mon Sep 17 00:00:00 2001
From: Sergey Senozhatsky
Date: Tue, 29 Aug 2017 22:30:07 +0900
Subject: [PATCH] printk: restore non-l
Hi!
On Mon 2017-08-28 21:21:09, Sergey Senozhatsky wrote:
> On (08/28/17 19:28), Sergey Senozhatsky wrote:
> > On (08/28/17 11:05), Pavel Machek wrote:
> > > Hi!
> > >
> > > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > > foo\nbar. That's... quite surprising/unwelcome. What is go
On (08/28/17 21:21), Sergey Senozhatsky wrote:
> how about something like this?
>
...ok, definetely breaks the
KERN_ERR "foo"; KERN_CONT "bar"; KERN_CONT "bar"; KERN_CONT "\n";
case. um... something like this then?
---
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index
On (08/28/17 19:28), Sergey Senozhatsky wrote:
> On (08/28/17 11:05), Pavel Machek wrote:
> > Hi!
> >
> > In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> > foo\nbar. That's... quite surprising/unwelcome. What is going on
> > there? Are timestamps responsible?
>
> well, one thing we k
On (08/28/17 11:05), Pavel Machek wrote:
> Hi!
>
> In 4.13-rc, printk("foo"); printk("bar"); seems to produce
> foo\nbar. That's... quite surprising/unwelcome. What is going on
> there? Are timestamps responsible?
well, one thing we know for sure it is not related to this patch set ;)
does any
Hi!
In 4.13-rc, printk("foo"); printk("bar"); seems to produce
foo\nbar. That's... quite surprising/unwelcome. What is going on
there? Are timestamps responsible?
Pavel
70 matches
Mail list logo
