All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boichat <drinkcat@chromium.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	devel@driverdev.osuosl.org, lkml <linux-kernel@vger.kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Douglas Anderson <dianders@chromium.org>,
	Guenter Roeck <groeck@chromium.org>,
	Joe Perches <joe@perches.com>
Subject: Re: [PATCH v4 3/3] media: atomisp: Only use trace_printk if allowed
Date: Fri, 21 Aug 2020 20:19:52 +0800	[thread overview]
Message-ID: <CANMq1KAuB4fCg50=G9ed_ALaD7O8=3PWQQMZNit52As-r7to4Q@mail.gmail.com> (raw)
In-Reply-To: <20200820230105.1f9651b7@oasis.local.home>

On Fri, Aug 21, 2020 at 11:01 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 21 Aug 2020 10:39:02 +0800
> Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> > I'm not sure how that helps? I mean, the use case you have in mind is
> > somebody reusing a distro/random config and not being able to use
> > trace_printk, right? If that config has CONFIG_DISABLE_TRACE_PRINTK=y,
> > then the developer will still need to flip that back.
> >
> > Note that the option I'm added has default=y (_allow_ trace_printk),
> > so I don't think default y or default n really matters?
>
> Ideally, the production system doesn't have it set. It only sets it to
> make sure that it's clean before sending out. But then it can add it
> back before production. Yeah, it's pretty much cutting hairs between
> the two. I don't like either one.
>
> Really, if you are worried about this, just add your patch to your
> local tree. I'm not sure this is something that can be fixed upstream.
>
> Another idea is to add something like below, and build with:
>
>  make CHECK_TRACE_PRINT=1
>
> This way it is a build command line option that causes the build to
> fail if trace_printk() is added.
>
> This way production systems can add this to make sure their kernels are
> free of trace_printk() but it doesn't affect the config that is used.

(for some reason I missed this reply in the thread ,-P)

Thanks, that's quite a nice idea, I'll try it out (not sure if we
still want that build_assert trick). We'd lose the automatic detection
of issues through randconfig kernel test robot, but hopefully if
enough distros enable it they'll start filing reports about issues.

And maybe we can use that in combination with a checkpatch.pl check.

(it turns out I'm having a hard time finding a good spot for this test
in our Chrome OS build infra, so an upstream-friendly solution would
be much better ,-P)

>
> -- Steve
>
> [ Not even compiled tested! ]
>
> diff --git a/Makefile b/Makefile
> index 2057c92a6205..5714a738879d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -91,6 +91,13 @@ else
>    Q = @
>  endif
>
> +ifeq ("$(origin CHECK_TRACE_PRINTK)", "command line")
> +  KBUILD_NO_TRACE_PRINTK = $(NO_TRACE_PRINTK)
> +endif
> +ifndef KBUILD_NO_TRACE_PRINTK
> +  KBUILD_NO_TRACE_PRINTK = 0
> +endif
> +
>  # If the user is running make -s (silent mode), suppress echoing of
>  # commands
>
> @@ -839,6 +846,10 @@ KBUILD_AFLAGS      += -gz=zlib
>  KBUILD_LDFLAGS += --compress-debug-sections=zlib
>  endif
>
> +ifeq ($(KBUILD_NO_TRACE_PRINTK),1)
> +KBUILD_CFLAGS += -DNO_TRACE_PRINTK
> +endif
> +
>  KBUILD_CFLAGS += $(DEBUG_CFLAGS)
>  export DEBUG_CFLAGS
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 500def620d8f..bee432547d26 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -680,11 +680,14 @@ extern void tracing_stop(void);
>  static inline __printf(1, 2)
>  void ____trace_printk_check_format(const char *fmt, ...)
>  {
> +#ifdef NO_TRACE_PRINTK
> +       extern void __no_trace_printk_on_build(void);
> +       __no_trace_printk_on_build();
> +#endif
>  }
>  #define __trace_printk_check_format(fmt, args...)                      \
>  do {                                                                   \
> -       if (0)                                                          \
> -               ____trace_printk_check_format(fmt, ##args);             \
> +       ____trace_printk_check_format(fmt, ##args);                     \
>  } while (0)
>
>  /**

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: devel@driverdev.osuosl.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Douglas Anderson <dianders@chromium.org>,
	Joe Perches <joe@perches.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Guenter Roeck <groeck@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH v4 3/3] media: atomisp: Only use trace_printk if allowed
Date: Fri, 21 Aug 2020 20:19:52 +0800	[thread overview]
Message-ID: <CANMq1KAuB4fCg50=G9ed_ALaD7O8=3PWQQMZNit52As-r7to4Q@mail.gmail.com> (raw)
In-Reply-To: <20200820230105.1f9651b7@oasis.local.home>

On Fri, Aug 21, 2020 at 11:01 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 21 Aug 2020 10:39:02 +0800
> Nicolas Boichat <drinkcat@chromium.org> wrote:
>
> > I'm not sure how that helps? I mean, the use case you have in mind is
> > somebody reusing a distro/random config and not being able to use
> > trace_printk, right? If that config has CONFIG_DISABLE_TRACE_PRINTK=y,
> > then the developer will still need to flip that back.
> >
> > Note that the option I'm added has default=y (_allow_ trace_printk),
> > so I don't think default y or default n really matters?
>
> Ideally, the production system doesn't have it set. It only sets it to
> make sure that it's clean before sending out. But then it can add it
> back before production. Yeah, it's pretty much cutting hairs between
> the two. I don't like either one.
>
> Really, if you are worried about this, just add your patch to your
> local tree. I'm not sure this is something that can be fixed upstream.
>
> Another idea is to add something like below, and build with:
>
>  make CHECK_TRACE_PRINT=1
>
> This way it is a build command line option that causes the build to
> fail if trace_printk() is added.
>
> This way production systems can add this to make sure their kernels are
> free of trace_printk() but it doesn't affect the config that is used.

(for some reason I missed this reply in the thread ,-P)

Thanks, that's quite a nice idea, I'll try it out (not sure if we
still want that build_assert trick). We'd lose the automatic detection
of issues through randconfig kernel test robot, but hopefully if
enough distros enable it they'll start filing reports about issues.

And maybe we can use that in combination with a checkpatch.pl check.

(it turns out I'm having a hard time finding a good spot for this test
in our Chrome OS build infra, so an upstream-friendly solution would
be much better ,-P)

>
> -- Steve
>
> [ Not even compiled tested! ]
>
> diff --git a/Makefile b/Makefile
> index 2057c92a6205..5714a738879d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -91,6 +91,13 @@ else
>    Q = @
>  endif
>
> +ifeq ("$(origin CHECK_TRACE_PRINTK)", "command line")
> +  KBUILD_NO_TRACE_PRINTK = $(NO_TRACE_PRINTK)
> +endif
> +ifndef KBUILD_NO_TRACE_PRINTK
> +  KBUILD_NO_TRACE_PRINTK = 0
> +endif
> +
>  # If the user is running make -s (silent mode), suppress echoing of
>  # commands
>
> @@ -839,6 +846,10 @@ KBUILD_AFLAGS      += -gz=zlib
>  KBUILD_LDFLAGS += --compress-debug-sections=zlib
>  endif
>
> +ifeq ($(KBUILD_NO_TRACE_PRINTK),1)
> +KBUILD_CFLAGS += -DNO_TRACE_PRINTK
> +endif
> +
>  KBUILD_CFLAGS += $(DEBUG_CFLAGS)
>  export DEBUG_CFLAGS
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 500def620d8f..bee432547d26 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -680,11 +680,14 @@ extern void tracing_stop(void);
>  static inline __printf(1, 2)
>  void ____trace_printk_check_format(const char *fmt, ...)
>  {
> +#ifdef NO_TRACE_PRINTK
> +       extern void __no_trace_printk_on_build(void);
> +       __no_trace_printk_on_build();
> +#endif
>  }
>  #define __trace_printk_check_format(fmt, args...)                      \
>  do {                                                                   \
> -       if (0)                                                          \
> -               ____trace_printk_check_format(fmt, ##args);             \
> +       ____trace_printk_check_format(fmt, ##args);                     \
>  } while (0)
>
>  /**
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2020-08-21 12:21 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-20  9:14 [PATCH v4 1/3, RESEND] media: camss: vfe: Use trace_printk for debugging only Nicolas Boichat
2020-08-20  9:14 ` [PATCH v4 2/3] kernel/trace: Add TRACING_ALLOW_PRINTK config option Nicolas Boichat
2020-08-20  9:14   ` [Intel-gfx] " Nicolas Boichat
2020-08-20  9:14   ` Nicolas Boichat
2020-08-20  9:14   ` [f2fs-dev] " Nicolas Boichat
2020-08-20  9:14 ` [PATCH v4 3/3] media: atomisp: Only use trace_printk if allowed Nicolas Boichat
2020-08-20  9:14   ` Nicolas Boichat
2020-08-20 14:23   ` Steven Rostedt
2020-08-20 14:23     ` Steven Rostedt
2020-08-21  0:13     ` Nicolas Boichat
2020-08-21  0:13       ` Nicolas Boichat
2020-08-21  0:36       ` Steven Rostedt
2020-08-21  0:36         ` Steven Rostedt
2020-08-21  1:39         ` Nicolas Boichat
2020-08-21  1:39           ` Nicolas Boichat
2020-08-21  1:57           ` Steven Rostedt
2020-08-21  1:57             ` Steven Rostedt
2020-08-21  2:36             ` Joe Perches
2020-08-21  2:36               ` Joe Perches
2020-08-21  2:42               ` Nicolas Boichat
2020-08-21  2:42                 ` Nicolas Boichat
2020-08-21  2:49                 ` Joe Perches
2020-08-21  2:49                   ` Joe Perches
2020-08-21  3:04                   ` Steven Rostedt
2020-08-21  3:04                     ` Steven Rostedt
2020-08-21  3:08                     ` Steven Rostedt
2020-08-21  3:08                       ` Steven Rostedt
2020-08-21  2:44               ` Steven Rostedt
2020-08-21  2:44                 ` Steven Rostedt
2020-08-21  2:39             ` Nicolas Boichat
2020-08-21  2:39               ` Nicolas Boichat
2020-08-21  3:01               ` Steven Rostedt
2020-08-21  3:01                 ` Steven Rostedt
2020-08-21 12:19                 ` Nicolas Boichat [this message]
2020-08-21 12:19                   ` Nicolas Boichat
2020-08-21  8:48         ` David Laight
2020-08-21  8:48           ` David Laight
2020-08-21 10:27           ` Nicolas Boichat
2020-08-21 10:27             ` Nicolas Boichat
2020-08-21 11:32             ` David Laight
2020-08-21 11:32               ` David Laight
2020-08-21 12:07               ` Nicolas Boichat
2020-08-21 12:07                 ` Nicolas Boichat
2020-08-21 12:18                 ` David Laight
2020-08-21 12:18                   ` David Laight
2020-08-21 12:37                   ` Nicolas Boichat
2020-08-21 12:37                     ` Nicolas Boichat
2020-08-20 14:21 ` [PATCH v4 1/3, RESEND] media: camss: vfe: Use trace_printk for debugging only Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANMq1KAuB4fCg50=G9ed_ALaD7O8=3PWQQMZNit52As-r7to4Q@mail.gmail.com' \
    --to=drinkcat@chromium.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@chromium.org \
    --cc=joe@perches.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.