linux-kernel - Re: [RFC PATCH 1/1] tracefs: add TP_printk_no_nl

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:   Mon, 31 Jul 2023 12:21:29 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Jim Cromie <jim.cromie@...il.com>, rostedt@...dmis.org,
        linux-kernel@...r.kernel.org,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        daniel@...ll.ch, sergey.senozhatsky@...il.com,
        Simon Ser <contact@...rsion.fr>,
        Sean Paul <seanpaul@...omium.org>
Subject: Re: [RFC PATCH 1/1] tracefs: add TP_printk_no_nl - RFC

On Mon 2023-07-31 10:31:03, John Ogness wrote:
> On 2023-07-30, Jim Cromie <jim.cromie@...il.com> wrote:
> > This variant of TP_printk() does *not* add the trailing newline.
> >
> > https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/
> >
> > taught dyndbg to send pr_debug() msgs to tracefs, via -x/T flag.
> >
> > It "reused" the include/trace/events/printk.h console event,
> > which does the following:
> >
> > 	TP_fast_assign(
> > 		/*
> > 		 * Each trace entry is printed in a new line.
> > 		 * If the msg finishes with '\n', cut it off
> > 		 * to avoid blank lines in the trace.
> > 		 */
> > 		if ((len > 0) && (text[len-1] == '\n'))
> > 			len -= 1;
> >
> > 		memcpy(__get_str(msg), text, len);
> > 		__get_str(msg)[len] = 0;
> > 	),
> >
> > That trim work could be avoided, *iff* all pr_debug() callers are
> > known to have no '\n' to strip.  While thats not true for *all*
> > callsites, it is 99+% true for DRM.debug callsites, and can be made
> > true for some subsets of prdbg/dyndbg callsites.
> 
> Note that the trailing '\n' in printk messages has a purpose.  It
> finalizes commitment of the message to the ringbuffer so that the
> message cannot be extended by any LOG_CONT printk's that may come along
> (from any context).

Also the message is printed on consoles only when finalized. As a
result, the last non-finalized message might not be visible on
consoles for hours or days.

> If it is not intended that a message is extended, then that message
> should include a trailing '\n'.
> 
> Grepping through the kernel, I am surprised how many messages are
> missing the trailing newline when it is obvious they are not intended to
> be extended. I consider these bugs.

I consider this bug as well.

My understanding is that this patch affects only messages printed to
the ftrace buffer so that it does not affect printk() directly.

But still. It creates a habit that is bad for printk(). Also relies
on the fact that people are aware of this macro and use it. IMHO,
it will not work in practice. Or do I miss something?

Best Regards,
Petr