linux-kernel - Re: [PATCH v4 3/3] media: atomisp: Only use 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: <20200820230804.7a9015af@oasis.local.home>
Date:   Thu, 20 Aug 2020 23:08:04 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Joe Perches <joe@...ches.com>
Cc:     Nicolas Boichat <drinkcat@...omium.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        devel@...verdev.osuosl.org, lkml <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Douglas Anderson <dianders@...omium.org>,
        Guenter Roeck <groeck@...omium.org>
Subject: Re: [PATCH v4 3/3] media: atomisp: Only use trace_printk if allowed

On Thu, 20 Aug 2020 23:04:59 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu, 20 Aug 2020 19:49:59 -0700
> Joe Perches <joe@...ches.com> wrote:
> 
> > Perhaps make trace_printk dependent on #define DEBUG?  
> 
> This is basically what Nicolas's patch series does in this very patch!
> 
> And no, I hate it. We are currently discussing ways of not having to
> modify the config in order to allow trace_printk() to be used.
> 
> We don't want to burden the developer to take a config, add a bunch of
> trace_printks() and find that it's compiled out!
>

This also breaks another use case. You may be working on a module for a
production kernel. It is fine to include trace_printk() in your module,
and load it on the production kernel. You will get that banner when you
load your module, but that's OK because it is still under development.

But something like this change will prevent that from happening.

-- Steve