All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Nicolas Boichat <drinkcat@chromium.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: Thu, 20 Aug 2020 23:01:05 -0400	[thread overview]
Message-ID: <20200820230105.1f9651b7@oasis.local.home> (raw)
In-Reply-To: <CANMq1KCpV+RKCqHsK-=Xeb+Vq28qdnBVF51rcga7m9-xjqNSCg@mail.gmail.com>

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.

-- 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: Steven Rostedt <rostedt@goodmis.org>
To: Nicolas Boichat <drinkcat@chromium.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: Thu, 20 Aug 2020 23:01:05 -0400	[thread overview]
Message-ID: <20200820230105.1f9651b7@oasis.local.home> (raw)
In-Reply-To: <CANMq1KCpV+RKCqHsK-=Xeb+Vq28qdnBVF51rcga7m9-xjqNSCg@mail.gmail.com>

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.

-- 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  3:01 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 [this message]
2020-08-21  3:01                 ` Steven Rostedt
2020-08-21 12:19                 ` Nicolas Boichat
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=20200820230105.1f9651b7@oasis.local.home \
    --to=rostedt@goodmis.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=dianders@chromium.org \
    --cc=drinkcat@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=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.