[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f84781f12424cbfa552981af42dfaf2@AcuMS.aculab.com>
Date: Mon, 24 Aug 2020 08:26:13 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Nicolas Boichat' <drinkcat@...omium.org>,
Steven Rostedt <rostedt@...dmis.org>
CC: "dianders@...omium.org" <dianders@...omium.org>,
"groeck@...omium.org" <groeck@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
"Guilherme G. Piccoli" <gpiccoli@...onical.com>,
Kars Mulder <kerneldev@...smulder.nl>,
Kees Cook <keescook@...omium.org>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Thomas Gleixner <tglx@...utronix.de>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Will Deacon <will@...nel.org>, Yue Hu <huyue2@...ong.com>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5] kernel/trace: Add DISALLOW_TRACE_PRINTK make option
From: Nicolas Boichat
> Sent: 24 August 2020 03:59
>
> trace_printk is meant as a debugging tool, and should not be
> compiled into production code without specific debug Kconfig
> options enabled, or source code changes, as indicated by the
> warning that shows up on boot if any trace_printk is called:
> ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> ** **
> ** trace_printk() being used. Allocating extra memory. **
> ** **
> ** This means that this is a DEBUG kernel and it is **
> ** unsafe for production use. **
>
> If DISALLOW_TRACE_PRINTK=1 is passed on the make command
> line, the kernel will generate a build-time error if
> trace_printk is used. We expect distributors to set this
> option for their production kernels.
>
> Note that the code to handle trace_printk is still present,
> so this does not prevent people from compiling out-of-tree
> kernel modules, or BPF programs.
>
> Also, we are not making this a kernel config option as we
> want the developer convenience of being able to reuse a
> production kernel config, add trace_printk for debugging,
> and rebuild, without any config changes.
Since the objective seems to be to ensure there are no
calls to trace_printk() in the git tree, but to allow
them in uncommitted sources. Why not use a config option
and rely on rand-config builds to detect any 'accidental'
commits?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists