Messages in this thread | | | Subject | Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() | From | Tetsuo Handa <> | Date | Fri, 29 May 2020 09:07:32 +0900 |
| |
On 2020/05/29 4:50, Linus Torvalds wrote: > On Thu, May 28, 2020 at 8:17 AM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: >> >> CONFIG_TWIST_FOR_SYZKALLER_TESTING is meant for linux-next only. >> But CONFIG_TWIST_KERNEL_BEHAVIOR is meant for Linus's tree. > > I really absolutely still detest this all. I don't see the point. The > naming is completely random (both "twist" and then options like > "TWIST_FOR_SYZKALLER_TESTING" that have no conceptual meaning.
Oh, I made copy&paste error. I wanted to say
CONFIG_TWIST_KERNEL_BEHAVIOR and CONFIG_TWIST_FOR_SYZKALLER_TESTING are meant for Linus's tree.
CONFIG_DEBUG_AID_FOR_SYZBOT is meant for linux-next only, and will be removed after CONFIG_TWIST_FOR_SYZKALLER_TESTING went to Linus's tree.
If you don't like the name "CONFIG_TWIST_FOR_SYZKALLER_TESTING", I'm happy to rename it.
> > I still don't understand why this small set of random options couldn't > just be kernel options that get set on the command line, and that have > independent and sane and explainable behavior?
You mean "export these behavior as kernel command line options"? That will involve run-time costs (while build-time branching based on #ifdef can completely eliminate run-time costs). Also, as number of options which can be controlled at boot-time grows, the kernel command line will become too long to specify all of these behavior. Also, making these options controllable at boot-time involves making these options as user-visible ABI (which is bad, for the twists which we want might change in the future).
> Why this odd mentality of "syzkaller is special"?
Why do you think "syzkaller is special" ? There is no syzkaller-specific choice. CONFIG_TWIST_FOR_SYZKALLER_TESTING is intended for eliminating the need of managing CONFIG_TWIST_* options on each kernel tree/commit. When a different fuzzer (or some kernel testing project) appears, they can define their own CONFIG_TWIST_FOR_$projectname_TESTING as well.
> > I've complained about this whole thing before. I'm getting really fed > up with this whole concept of "magic crazy config options". > > The kernel configuration phase is just about the _worst_ part of the > kernel, we shouldn't make these pointless things make it even worse.
Current kernel is not well segmented enough to allow switching based on per process flags. We can't distinguish whether some kernel message was caused by a process with such flags.
All we could afford is to switch based on kernel boot command line. But that will entail a lot of code/data (and runtime-cost) which is not used if the administrator does not turn on the switches.
After all, switching at the kernel configuration phase is the most simple approach.
On 2020/05/29 5:01, Linus Torvalds wrote: > On Thu, May 28, 2020 at 12:50 PM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> I still don't understand why this small set of random options couldn't >> just be kernel options that get set on the command line, and that have >> independent and sane and explainable behavior? Why this odd mentality >> of "syzkaller is special"? > > And just to clarify: the kernel option wouldn't be "syzcaller_twist" > or something insane like that. > > It would be something like "kbd-disable-hotkeys" or whatever: actual > real text that says what it does.
If you don't like the name "CONFIG_TWIST_FOR_SYZKALLER_TESTING", please suggest an example name you would accept. But if you don't like switching based on the kernel configuration options, I can't find a better solution.
| |