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]

Date:   Wed, 22 Jul 2020 20:37:10 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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>,
        John Ogness <john.ogness@...utronix.de>
Subject: Re: [PATCH] dynamic debug: allow printing to trace event

On (20/07/21 17:30), Steven Rostedt wrote:
> On Tue, 21 Jul 2020 16:11:05 +0200
> Vincent Whitchurch <vincent.whitchurch@...s.com> wrote:
> 
> > When debugging device drivers, I've found it very useful to be able to
> > redirect existing pr_debug()/dev_dbg() prints to the trace buffer
> > instead of dmesg.  Among the many advantages of the trace buffer is that
> > it can be dynamically resized, allows these prints to combined with
> > other trace events, and doesn't fill up system logs.
> > 
> > Since dynamic debug already has hooks in these call sites, getting these
> > prints into the ftrace buffer is straightforward if we have dynamic
> > debug do it.
> > 
> > Add an "x" flag to make the dynamic debug call site print to a new
> > printk:dynamic trace event.  The trace event can be emitted instead of
> > or in addition to the printk().  The print buffer is placed on the stack
> > and is limited to a somewhat arbitrarily chosen 256 bytes; anything
> > larger will be truncated.
> 
> Is it safe to have a 256 byte string on the stack? That's quite a bit.
> How deep is the stack when this is called?
> 
> You could run vsnprintf() with a zero length to get the size, and then
> just allocate that from the ring buffer. How critical is the performance?

Hmm.
Can trace event contain a fixed size buffer or a dynamic array; then
we'll pass fmt and va_list to trace event so it can vscnprintf() into
its buffer in assign function?

	-ss