linux-kernel - Re: [PATCH] dynamic debug: allow printing to trace event

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: <20200723113927.581af808@oasis.local.home>
Date:   Thu, 23 Jul 2020 11:39:27 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Vincent Whitchurch <vincent.whitchurch@...s.com>,
        jbaron@...mai.com, mingo@...hat.com, kernel@...s.com,
        corbet@....net, linux-kernel@...r.kernel.org,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCH] dynamic debug: allow printing to trace event

On Thu, 23 Jul 2020 16:08:44 +0206
John Ogness <john.ogness@...utronix.de> wrote:

> For me a trace event represents a specific point in the kernel code. But
> this new printk trace event, instead, represents general log
> redirection. I do not oppose it, but it feels like a hack to me. In
> contrast, simply setting a dynamic printk flag to write the message
> string to the trace buffer (without also activating some pseudo trace
> event) feels more natural.

I agree with your sentiment. But my experience with the kernel is, if
you create an API for one subsystem, other subsystems are destined to
(ab)use it.

Now, trace_array_vprintk() is available too, which acts just like
trace_printk(), but requires creating a separate trace buffer to write
to. I'm fine with this because it wont cause noise in the top level
buffer.


> 
> Just sharing my thoughts, as requested.

Appreciated ;-)

-- Steve