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 +0900
>> > Subject: [PATCH] printk: Add caller
On Thu 2019-03-21 13:59:53, Michael Ellerman wrote:
> 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
> >
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 printk() output.
>
>
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 want to print a series of
On 2018/12/17 23:54, Petr Mladek wrote:
> 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
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 want to print a series
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 disturbed by
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 disturbed by concurrent
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
On 2018/12/05 0:27, Petr Mladek wrote:
> 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 >=
On 2018/12/05 0:27, Petr Mladek wrote:
> 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 >=
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]
On 2018/12/01 23:44, 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] Performance Events:
On 2018/12/01 23:44, 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] Performance Events:
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
51 matches
Mail list logo
