Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4C19B217BA
Date:   Tue, 24 Apr 2018 15:14:16 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Wei Wang <wvw@google.com>
Cc:     gregkh@linuxfoundation.org, Wei Wang <wei.vince.wang@gmail.com>,
        Ingo Molnar <mingo@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Crt Mori <cmo@melexis.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        linux-kernel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [PATCH] do not call trace_printk on non-debug build
Message-ID: <20180424151416.397fbbde@gandalf.local.home>
In-Reply-To: <CAGXk5yo44kAku+ZYx=8HzOgkEVC7ARNSER4MvWTCz-i51up=ew@mail.gmail.com>
References: <20180424180812.215900-1-wvw@google.com>
        <20180424145056.7c29ea18@gandalf.local.home>
        <CAGXk5yo44kAku+ZYx=8HzOgkEVC7ARNSER4MvWTCz-i51up=ew@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 24 Apr 2018 19:02:34 +0000
Wei Wang <wvw@google.com> wrote:

> 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."

The thing is, trace_printk() should not be used except for development
and debugging. There should be no use cases in the kernel that us it,
unless it's part of something else that should never be used (I use it
for the ring buffer benchmark which itself will destabilize the
system and is why I use it - I want that warning for it too).

Any trace_printk() in a patch submitted to the kernel should simply be
stripped out. If someone wants a trace_printk() in their code, then
they should create a trace event, which is the proper way of retrieving
static data from the kernel. Using trace_printk() is just a lazy fast
way to create trace events.

Hmm, ideally I think check_patch needs to add a warning if
trace_printk() is used.

-- Steve