Re: twist: allow disabling reboot request

From: Petr Mladek
Date: Wed Jun 03 2020 - 08:44:11 EST


On Wed 2020-06-03 20:03:28, Tetsuo Handa wrote:
> On 2020/05/29 22:26, Tetsuo Handa wrote:
> > By the way, I do worry that people forget to perform these steps when they do
> > their tests without asking syzbot...
>
> Here is a draft of boot-time switching. Since kconfig can handle string variable up to
> 2048 characters, we could hold the content of the "your-config" file inside .config file
> in order to avoid relying on external file in "syzkaller tree". But since only one kconfig
> option is used, basically the way to temporarily include/exclude specific options (under
> automated testing by syzbot) seems to remain directly patching apply_twist_flags(), for
> https://github.com/google/syzkaller/blob/master/dashboard/config/util.sh will automatically
> overwrite CONFIG_DEFAULT_TWIST_FLAGS settings. If each twist flag were using independent
> kconfig option, the way to temporarily include/exclude specific options will become directly
> patching Kconfig file.
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 82d91547d122..78fdbb4f17b1 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -1038,4 +1038,12 @@ static inline void ftrace_dump(enum ftrace_dump_mode oops_dump_mode) { }
> /* OTHER_WRITABLE? Generally considered a bad idea. */ \
> BUILD_BUG_ON_ZERO((perms) & 2) + \
> (perms))
> +
> +/* Flags for twisting kernel behavior. */
> +struct twist_flags {
> + bool disable_kbd_k_spec_handler;
> + bool disable_reboot_request;
> +};
> +extern struct twist_flags twist_flags;


Why all these options have to be in a single structure?


> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 498d344ea53a..41cfabc74ad7 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2338,4 +2338,9 @@ config HYPERV_TESTING
>
> endmenu # "Kernel Testing and Coverage"
>
> +menuconfig DEFAULT_TWIST_FLAGS
> + string "Default twist options (DANGEROUS)"
> + help
> + Don't specify anything unless you know what you are doing.
> +
> endmenu # Kernel hacking

Why such a crazy build configure option?

I think that the only way to get this upstream is to:

+ Add separate boot options that might theoretically be used also
by other people.

+ Use boot parameters and not build configuration.

+ Avoid the meaningless word "twist" !!!


Best Regards,
Petr