Petr Mladek writes:
> On Thu 2019-03-21 13:59:53, Michael Ellerman wrote:
>> Tetsuo Handa writes:
>> ...
>> > From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001
>> > From: Tetsuo Handa
>> > Date: Tue, 18 Dec 2018 05:53:04 +090
ate: Tue, 18 Dec 2018 05:53:04 +0900
> > Subject: [PATCH] printk: Add caller information to printk() output.
> >
> > Sometimes we want to print a series of printk() messages to consoles
> > without being disturbed by concurrent printk() from interrupts and/or
> > other
Hi Tetsuo,
Thanks for implementing this, it's really helpful.
Tetsuo Handa writes:
...
> From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 18 Dec 2018 05:53:04 +0900
> Subject: [PATCH] printk: Add caller information to pri
Dmitry Vyukov writes:
> On Wed, Jan 2, 2019 at 5:09 PM Dmitry Vyukov wrote:
>>
>> On Tue, Dec 18, 2018 at 9:58 AM Sergey Senozhatsky
>> wrote:
>> >
>> > On (12/18/18 09:39), Petr Mladek wrote:
>> > >
>> > > Sergey, are you okay with this squashed patch, please?
>> > >
>> >
>> > Yeah. There are
On 2018/12/18 17:58, Sergey Senozhatsky wrote:
> On (12/18/18 09:39), Petr Mladek wrote:
>>
>> Sergey, are you okay with this squashed patch, please?
>>
>
> Yeah. There are several minor nitpicks, but here is my
> Acked-by: Sergey Senozhatsky
>
>
> One final question - can syzbot folks confirm
On Thu, Jan 03, 2019 at 07:27:41PM +0100, Dmitry Vyukov wrote:
On Wed, Jan 2, 2019 at 5:09 PM Dmitry Vyukov wrote:
On Tue, Dec 18, 2018 at 9:58 AM Sergey Senozhatsky
wrote:
>
> On (12/18/18 09:39), Petr Mladek wrote:
> >
> > Sergey, are you okay with this squashed patch, please?
> >
>
>
On Wed, Jan 2, 2019 at 5:09 PM Dmitry Vyukov wrote:
>
> On Tue, Dec 18, 2018 at 9:58 AM Sergey Senozhatsky
> wrote:
> >
> > On (12/18/18 09:39), Petr Mladek wrote:
> > >
> > > Sergey, are you okay with this squashed patch, please?
> > >
> >
> > Yeah. There are several minor nitpicks, but here is
On Tue, Dec 18, 2018 at 9:58 AM Sergey Senozhatsky
wrote:
>
> On (12/18/18 09:39), Petr Mladek wrote:
> >
> > Sergey, are you okay with this squashed patch, please?
> >
>
> Yeah. There are several minor nitpicks, but here is my
> Acked-by: Sergey Senozhatsky
>
>
> One final question - can syzbot
On (12/18/18 11:01), Petr Mladek wrote:
> I have updated the patch in printk.git, for-4.22 branch.
Thanks.
> PS: I think that I have rushed the patch probably too much.
> I did too much nitpicking in the past and am trying to find
> a better balance now.
It's all good.
-ss
On Tue 2018-12-18 17:55:24, Sergey Senozhatsky wrote:
> On (12/18/18 06:05), Tetsuo Handa wrote:
> > +#ifdef CONFIG_PRINTK_CALLER
> > +static size_t print_caller(u32 id, char *buf)
> > +{
> > + char from[12];
> > +
> > + snprintf(from, sizeof(from), "%c%u",
> > +id & 0x8000 ?
On (12/18/18 09:39), Petr Mladek wrote:
>
> Sergey, are you okay with this squashed patch, please?
>
Yeah. There are several minor nitpicks, but here is my
Acked-by: Sergey Senozhatsky
One final question - can syzbot folks confirm that the patch
helps? Just curious.
-ss
On (12/18/18 06:05), Tetsuo Handa wrote:
> +#ifdef CONFIG_PRINTK_CALLER
> +static size_t print_caller(u32 id, char *buf)
> +{
> + char from[12];
> +
> + snprintf(from, sizeof(from), "%c%u",
> + id & 0x8000 ? 'C' : 'T', id & ~0x8000);
> + return sprintf(buf,
On Tue 2018-12-18 06:05:04, Tetsuo Handa wrote:
> >From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 18 Dec 2018 05:53:04 +0900
> Subject: [PATCH] printk: Add caller information to printk() output.
>
> Sometimes we w
;,
> id & 0x8000 ? 'C' : 'T', id & ~0x8000);
Updated to [20] in case memory corruption like
CPU: 0 PID: -2035180937 Comm: L � Not tainted 4.20.0-rc6+ #344
happened.
>From 91f85d2bd494df2f73c605d8b4747e8cc0a61ae2 Mon Sep 17 00:00:00 2001
From: Tetsuo
On (12/17/18 15:54), Petr Mladek wrote:
> Now, I always felt that the "from" name was a bit strange but
> nothing better came to my mind until today.
Could be printk_caller, could be printk_origin. I don't have strong
preferences.
> I would like to rename "from" to "caller", see the patch below.
On Thu 2018-12-13 21:42:55, Sergey Senozhatsky wrote:
> On (12/13/18 13:18), Petr Mladek wrote:
> > > Sometimes we want to print a series of printk() messages to consoles
> > > without being disturbed by concurrent printk() from interrupts and/or
> > > other threads. But we can't enforce printk()
On (12/13/18 13:18), Petr Mladek wrote:
> > Sometimes we want to print a series of printk() messages to consoles
> > without being disturbed by concurrent printk() from interrupts and/or
> > other threads. But we can't enforce printk() callers to use their local
> > buffers because we need to ask
On Tue 2018-12-11 19:26:48, Tetsuo Handa wrote:
> >From bdb80508390694456f3f864f9651d047ded109bf Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Tue, 11 Dec 2018 19:23:30 +0900
> Subject: [PATCH v4] printk: Add caller information to printk() output.
>
> Sometimes we w
On (12/12/18 11:25), Sergey Senozhatsky wrote:
> On (12/11/18 19:26), Tetsuo Handa wrote:
> > @@ -688,12 +701,21 @@ static ssize_t msg_print_ext_header(char *buf, size_t
> > size,
> > struct printk_log *msg, u64 seq)
> > {
> > u64 ts_usec = msg->ts_nsec;
> > +
On (12/11/18 19:26), Tetsuo Handa wrote:
> @@ -688,12 +701,21 @@ static ssize_t msg_print_ext_header(char *buf, size_t
> size,
> struct printk_log *msg, u64 seq)
> {
> u64 ts_usec = msg->ts_nsec;
> + char from[18];
[..]
> +#ifdef CONFIG_PRINTK_FROM
>
>From bdb80508390694456f3f864f9651d047ded109bf Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 11 Dec 2018 19:23:30 +0900
Subject: [PATCH v4] printk: Add caller information to printk() output.
Sometimes we want to print a series of printk() messages to consoles
without being distur
On 2018/12/10 22:09, Petr Mladek wrote:
>> +#ifdef CONFIG_PRINTK_FROM
>> +#define PREFIX_FROM_MAX 16
>> +#define PREFIX_MAX (32 + PREFIX_FROM_MAX)
>> +#define LOG_LINE_MAX(1024 - 32)
>
> This looks suspicious. We either need to limit LOG_LINE_MAX
> by the real
On Wed 2018-12-05 19:42:22, Tetsuo Handa wrote:
> From: Tetsuo Handa
> Date: Wed, 5 Dec 2018 16:53:08 +0900
> Subject: [PATCH v3] printk: Add caller information to printk() output.
>
> Sometimes we want to print a series of printk() messages to consoles
> without being distu
On (12/07/18 13:58), Tetsuo Handa wrote:
> > All you need is a way to reconstruct a message around
> > some very specific place in the log - say in a range [-500, +500] lines,
> > assuming that a backtrace you are trying to reconstruct is badly fragmented.
> > I think, even 3
On (12/07/18 13:58), Tetsuo Handa wrote:
> > All you need is a way to reconstruct a message around
> > some very specific place in the log - say in a range [-500, +500] lines,
> > assuming that a backtrace you are trying to reconstruct is badly fragmented.
> > I think, even 3
Sergey Senozhatsky wrote:
> Do we need PIDs at all?
Yes. I don't like truncating caller information, for I think that PID is
used for not only reconstructing messages but also serving as a clue for
understanding what the process was doing.
> PIDs don't tell that much. When you are grepping
Sergey Senozhatsky wrote:
> Do we need PIDs at all?
Yes. I don't like truncating caller information, for I think that PID is
used for not only reconstructing messages but also serving as a clue for
understanding what the process was doing.
> PIDs don't tell that much. When you are grepping
On (12/05/18 19:42), Tetsuo Handa wrote:
> >>
> >> PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used.
> >
> > 4194304 is the worst case. I would use the same approach as with the
> > timestamp seconds. It uses 5 characters as the minimum. But it might
> > eventully get
On (12/05/18 19:42), Tetsuo Handa wrote:
> >>
> >> PID_MAX_LIMIT is 4194304, which can take up to 10 bytes if [T%u] is used.
> >
> > 4194304 is the worst case. I would use the same approach as with the
> > timestamp seconds. It uses 5 characters as the minimum. But it might
> > eventully get
] looks like a reasonable default.
>
While "%5lu.%06lu" for uptime does not decrease over time (and hence changing
to "%lu.%06lu" does not cause wavy output), "[%6s]" for T$thread_id will cause
wavy output after PID reached 10. Isn't it hard to parse after al
] looks like a reasonable default.
>
While "%5lu.%06lu" for uptime does not decrease over time (and hence changing
to "%lu.%06lu" does not cause wavy output), "[%6s]" for T$thread_id will cause
wavy output after PID reached 10. Isn't it hard to parse after al
On Tue 2018-12-04 19:16:56, Tetsuo Handa wrote:
> On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> >> +config PRINTK_FROM
> >> + bool "Show caller information on printks"
> >> + depends on PRINTK
> >
> > Wasn't it supposed to also depend on DEBUG_AID_FOR_SYZBOT?
>
> CONFIG_DEBUG_AID_FOR_SYZBOT
On Tue 2018-12-04 19:16:56, Tetsuo Handa wrote:
> On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> >> +config PRINTK_FROM
> >> + bool "Show caller information on printks"
> >> + depends on PRINTK
> >
> > Wasn't it supposed to also depend on DEBUG_AID_FOR_SYZBOT?
>
> CONFIG_DEBUG_AID_FOR_SYZBOT
On Tue 2018-12-04 06:10:40, Tetsuo Handa wrote:
> On 2018/12/04 0:06, Petr Mladek wrote:
> >> If we modify print_time(), I think that the leading spaces inserted by
> >> "%5lu"
> >> makes little sense, for "%5lu" is too small for systems with uptime >=
> >> 1.16 days
> >> and parsers after all
On Tue 2018-12-04 06:10:40, Tetsuo Handa wrote:
> On 2018/12/04 0:06, Petr Mladek wrote:
> >> If we modify print_time(), I think that the leading spaces inserted by
> >> "%5lu"
> >> makes little sense, for "%5lu" is too small for systems with uptime >=
> >> 1.16 days
> >> and parsers after all
On (12/04/18 19:16), Tetsuo Handa wrote:
> On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> > On (12/02/18 20:23), Tetsuo Handa wrote:
> >>
> >> Some examples for console output:
> >>
> >> [0.919699]@T1 x86: Booting SMP configuration:
> >> [4.152681]@T271 Fusion MPT base driver 3.04.20
On (12/04/18 19:16), Tetsuo Handa wrote:
> On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> > On (12/02/18 20:23), Tetsuo Handa wrote:
> >>
> >> Some examples for console output:
> >>
> >> [0.919699]@T1 x86: Booting SMP configuration:
> >> [4.152681]@T271 Fusion MPT base driver 3.04.20
On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> On (12/02/18 20:23), Tetsuo Handa wrote:
>>
>> Some examples for console output:
>>
>> [0.919699]@T1 x86: Booting SMP configuration:
>> [4.152681]@T271 Fusion MPT base driver 3.04.20
>> [5.070470]@C0 random: fast init done
>> [
On 2018/12/04 11:02, Sergey Senozhatsky wrote:
> On (12/02/18 20:23), Tetsuo Handa wrote:
>>
>> Some examples for console output:
>>
>> [0.919699]@T1 x86: Booting SMP configuration:
>> [4.152681]@T271 Fusion MPT base driver 3.04.20
>> [5.070470]@C0 random: fast init done
>> [
On (12/02/18 20:23), Tetsuo Handa wrote:
>
> Some examples for console output:
>
> [0.919699]@T1 x86: Booting SMP configuration:
> [4.152681]@T271 Fusion MPT base driver 3.04.20
> [5.070470]@C0 random: fast init done
> [6.587900]@C3 random: crng init done
This is hard to
On (12/02/18 20:23), Tetsuo Handa wrote:
>
> Some examples for console output:
>
> [0.919699]@T1 x86: Booting SMP configuration:
> [4.152681]@T271 Fusion MPT base driver 3.04.20
> [5.070470]@C0 random: fast init done
> [6.587900]@C3 random: crng init done
This is hard to
On 2018/12/04 0:06, Petr Mladek wrote:
>> If we modify print_time(), I think that the leading spaces inserted by "%5lu"
>> makes little sense, for "%5lu" is too small for systems with uptime >= 1.16
>> days
>> and parsers after all cannot assume fixed length for the timestamp field.
>> Then,
>>
On 2018/12/04 0:06, Petr Mladek wrote:
>> If we modify print_time(), I think that the leading spaces inserted by "%5lu"
>> makes little sense, for "%5lu" is too small for systems with uptime >= 1.16
>> days
>> and parsers after all cannot assume fixed length for the timestamp field.
>> Then,
>>
On Sat 2018-12-01 23:44:37, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
> >> Some examples for console output:
> >>
> >> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
> >> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
> >> [0.299733] [T1]
On Sat 2018-12-01 23:44:37, Tetsuo Handa wrote:
> On 2018/12/01 0:40, Petr Mladek wrote:
> >> Some examples for console output:
> >>
> >> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
> >> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
> >> [0.299733] [T1]
e PREFIX_MAX definition
after "[PATCH v2] printk: fix printk_time race." is applied).
>From 48603394cc0c8c5ad9ee57bc665dfd2c421e923b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 2 Dec 2018 19:41:02 +0900
Subject: [PATCH v2] printk: Add caller information to printk() output.
e PREFIX_MAX definition
after "[PATCH v2] printk: fix printk_time race." is applied).
>From 48603394cc0c8c5ad9ee57bc665dfd2c421e923b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 2 Dec 2018 19:41:02 +0900
Subject: [PATCH v2] printk: Add caller information to printk() output.
On 2018/12/01 0:40, Petr Mladek wrote:
>> Some examples for console output:
>>
>> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
>> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
>> [0.299733] [T1] Performance Events: Haswell events, core PMU driver.
>> [
On 2018/12/01 0:40, Petr Mladek wrote:
>> Some examples for console output:
>>
>> [0.293000] [T1] smpboot: CPU0: Intel(R) Core(TM) i5-4440S CPU @
>> 2.80GHz (family: 0x6, model: 0x3c, stepping: 0x3)
>> [0.299733] [T1] Performance Events: Haswell events, core PMU driver.
>> [
On Sat 2018-11-24 16:37:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> We tried to allow printk() callers to explicitly use
On Sat 2018-11-24 16:37:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> We tried to allow printk() callers to explicitly use
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
We tried to allow printk() callers to explicitly use their local buffer
in order to make sure that a whole line
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
We tried to allow printk() callers to explicitly use their local buffer
in order to make sure that a whole line
53 matches
Mail list logo
