linux-kernel - Re: [PATCH] do not call trace

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: <CAGXk5yo44kAku+ZYx=8HzOgkEVC7ARNSER4MvWTCz-i51up=ew@mail.gmail.com>
Date:   Tue, 24 Apr 2018 19:02:34 +0000
From:   Wei Wang <wvw@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     gregkh@...uxfoundation.org, Wei Wang <wei.vince.wang@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Crt Mori <cmo@...exis.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] do not call trace_printk on non-debug build

We have seen many cases vendor have shipped kernel/drivers with it, and
have to clean up that every year. This was brought up in an internal
discussion and Greg suggested have some feedback from upstream about what
should be taken to prevent this globally besides fixing individual drivers.
 From him "I think this change makes sense at a high level, but there could
be non-obvious reasons why this isn't the way things are handled right now."
On Tue, Apr 24, 2018 at 11:51 AM Steven Rostedt <rostedt@...dmis.org> wrote:

> On Tue, 24 Apr 2018 11:08:10 -0700
> Wei Wang <wvw@...gle.com> wrote:

> > From: Wei Wang <wvw@...gle.com>
> >
> > trace_printk will cause trace_printk_init_buffers executed in kernel
> > start, which will increase memory and also show bad warnings in
> > production kernel.
> >

> NAK!

> Where is trace_printk() being used to trigger this?

> trace_printk() is to be added while debugging, but one should not need
> to enable DEBUG to use it. But it should be removed when finished.

Yeah, ideal case is it *should* be removed, but if this is not for
production use, does it make sense we limit the usage with DEBUG?

> -- Steve

> > Signed-off-by: Wei Wang <wvw@...gle.com>