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
| ||
|
Date: Fri, 6 May 2022 16:55:10 +0200 From: Marco Elver <elver@...gle.com> To: Petr Mladek <pmladek@...e.com> Cc: John Ogness <john.ogness@...utronix.de>, Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com, Thomas Gleixner <tglx@...utronix.de>, Johannes Berg <johannes.berg@...el.com>, Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Naresh Kamboju <naresh.kamboju@...aro.org>, Linux Kernel Functional Testing <lkft@...aro.org> Subject: Re: [PATCH -printk] printk, tracing: fix console tracepoint On Fri, 6 May 2022 at 16:51, Petr Mladek <pmladek@...e.com> wrote: > > On Wed 2022-05-04 11:46:36, Petr Mladek wrote: > > On Tue 2022-05-03 21:20:44, John Ogness wrote: > > > On 2022-05-03, Marco Elver <elver@...gle.com> wrote: > > > > One notable difference is that by moving tracing into printk_sprint(), > > > > the 'text' will no longer include the "header" (loglevel and timestamp), > > > > but only the raw message. Arguably this is less of a problem now that > > > > the console tracepoint happens on the printk() call and isn't delayed. > > > > > > Another slight difference is that messages composed of LOG_CONT pieces > > > will trigger the tracepoint for each individual piece and _never_ as a > > > complete line. > > > > > > It was never guaranteed that all LOG_CONT pieces make it into the final > > > printed line anyway, but with this change it will be guaranteed that > > > they are always handled separately. > > > > > > I am OK with this change, but like Steven, I agree the the users of that > > > tracepoint need to chime in. > > > > My feeling is that the feature is not used much. Otherwise people > > would complain that it was asynchronous and hard to use. > > > > I mean that the printk() messages appeared in the trace log > > asynchronously. So it required some post processing to correctly > > sort them against other tracing messages. The same result can be > > achieved by processing printk log buffer, dmesg.log, journalctl. > > > > I guess that we will only find the answer when we push the change > > into linux-next and mainline. I am going to do so. > > JFYI, the patch has been committed into printk/linux.git, > branch rework/kthreads. Thank you, sounds good. Thanks, -- Marco
Powered by blists - more mailing lists