linux-kernel - Re: [RFC PATCH v3 0/5] tracing: common error

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1552409351.4293.22.camel@kernel.org>
Date:   Tue, 12 Mar 2019 11:49:11 -0500
From:   Tom Zanussi <zanussi@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     rostedt@...dmis.org, tglx@...utronix.de, namhyung@...nel.org,
        bigeasy@...utronix.de, joel@...lfernandes.org,
        linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: [RFC PATCH v3 0/5] tracing: common error_log for ftrace

Hi Masami,

On Tue, 2019-03-12 at 15:26 +0900, Masami Hiramatsu wrote:
> Hi Tom,
> 
> On Tue, 5 Mar 2019 23:06:46 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > On Mon,  4 Mar 2019 17:36:43 -0600
> > > Changes from v2:
> > > 
> > >   - Added [n] numbering as suggested by Masami
> 
> Hmm, this seems a bit different what I suggested.
> 
> I'm trying to port probe event's error report on
> your error log, and I found that the number is
> just shifted as below.
> 
> When I filled the log with errors.
> =============
> /sys/kernel/debug/tracing # cat error_log 
> [1] trace_kprobe: error: Invalid unsigned integer string
>   Command: r10aa00:foo/bar vfs
>             ^
> ...
> 
> [7] trace_kprobe: error: Group name must follow C naming convention
>   Command: p:a-b/bar vfs_read
>              ^
> [8] trace_kprobe: error: Event name is too long
>   Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
> =============
> 
> And do one more error, 
> 
> =============
> /sys/kernel/debug/tracing # cat error_log 
> [1] trace_kprobe: error: Maxactive is too big
>   Command: r0xaa00:foo/bar vfs
> 
> ....
> 
> [7] trace_kprobe: error: Event name is too long
>   Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
>                ^
> [8] trace_kprobe: error: Event name must follow C naming convention
>   Command: p:a/bar.c vfs_read
>                ^
> =============
> 
> The number of logs are changed :(  This can confuse users.
> I think it is better to keep the number as a unique number for
> each entry as below.
> 

Hmm, that makes sense, but I wonder if that will also confuse users,
when the log wraps around and no longer starts at [1] and there's no
way to retrieve the previous errors.

I took your suggestion as a way mainly to clearly delineate each error,
since without the [number] or something similar, they all kind of run
together.

Not sure what advantage numbering itself provides - would some other
non-numbered separator work?

Thanks,

Tom

> =============
> /sys/kernel/debug/tracing # cat error_log 
> [2] trace_kprobe: error: Maxactive is too big
>   Command: r0xaa00:foo/bar vfs
> 
> ....
> 
> [8] trace_kprobe: error: Event name is too long
>   Command:
> p:a/barrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
> rrrrrrrrrrr vfs_read
>                ^
> [9] trace_kprobe: error: Event name must follow C naming convention
>   Command: p:a/bar.c vfs_read
>                ^
> =============
> 
> Thank you,
>