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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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