Re: twist: allow disabling reboot request

[Petr Mladek]

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