[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7728c978-d359-227f-0f3e-f975c45ca218@i-love.sakura.ne.jp>
Date: Sat, 21 Mar 2020 13:49:21 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Dmitry Vyukov <dvyukov@...gle.com>, Jiri Slaby <jslaby@...e.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Matthew Garrett <mjg59@...gle.com>,
Andi Kleen <ak@...ux.intel.com>,
"Theodore Y . Ts'o" <tytso@....edu>,
Alexander Viro <viro@...iv.linux.org.uk>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Arnd Bergmann <arnd@...db.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.
On 2020/03/10 15:30, Dmitry Vyukov wrote:
> Re making it a single config vs a set of fine-grained configs. I think
> making it fine-grained is a proper way to do it, but the point Tetsuo
> raised is very real and painful as well -- when a kernel developer
> adds another option, they will not go and update configs on all
> external testing systems. This problem is also common for "enable all
> boot tests that can run on this kernel", or "configure a 'standard'
> debug build". Currently doing these things require all of expertise,
> sacred knowledge, checking all configs one-by-one as well as checking
> every new kernel patch and that needs to be done by everybody doing
> any kernel testing.
> I wonder if this can be solved by doing fine-grained configs, but also
> adding some umbrella uber-config that will select all of the
> individual options. Config system allows this, right? With "select" or
> "default if" clauses. What would be better: have the umbrella option
> select all individual, or all individual default to y if umbrella is
> selected?
So, we have three questions.
Q1: Can we agree with adding build-time branching (i.e. kernel config options) ?
I fear bugs (e.g. unexpectedly overwrting flag variables) in run-time
branching mechanisms. Build-time branching mechanisms cannot have such bugs.
Q2: If we can agree with kernel config options, can we start with single (or
fewer) kernel config option (e.g. CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y) ?
Q3: If we can agree with kernel config options but we can't start with single
(or fewer) kernel config option, can we agree with adding another kernel
config option which selects all options (e.g.
config KERNEL_BUILT_FOR_FUZZ_TESTING
bool "Build kernel for fuzz testing"
config KERNEL_BUILT_FOR_FUZZ_TESTING_SELECT_ALL
bool "Select all options for Build kernel for fuzz testing"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
select KERNEL_DISABLE_FOO1
select KERNEL_DISABLE_BAR1
select KERNEL_DISABLE_BUZ1
select KERNEL_CHANGE_FOO2
select KERNEL_ENABLE_BAR2
config KERNEL_DISABLE_FOO1
bool "Disable foo1"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
config KERNEL_DISABLE_BAR1
bool "Disable bar1"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
config KERNEL_DISABLE_BUZ1
bool "Disable buz1"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
config KERNEL_CHANGE_FOO2
bool "Change foo2"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
config KERNEL_ENABLE_BAR2
bool "Enable bar2"
depends on KERNEL_BUILT_FOR_FUZZ_TESTING
) ?
Powered by blists - more mailing lists