Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp99738ybm; Thu, 28 May 2020 17:12:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzd0fos+pbQ5Ev7OhVpAzPnDiYEj062LJY+lQeRD9vg5uaT18Hzy6Q0lZNmH2pS3Dsxp/v X-Received: by 2002:a05:6402:c87:: with SMTP id cm7mr5649248edb.96.1590711141919; Thu, 28 May 2020 17:12:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590711141; cv=none; d=google.com; s=arc-20160816; b=bbSmieTaS03zZiDyDpCOdDQqNl4fl5Fe8P2x9S5xGl+kyV/6FUbw93Vqj5z3btBmsS 6iqPnuLKWK6B0BH9LppP59RNj9UGkodfHJn6Z+He921DaxkHUJ4YTGJzdEZ2GAz62g/s 9VwpvSJEZNouDC2QYt/92ih9FBa5/hgHh/zPfDQ6s6/3N8NvSV0XjvRBdIdzcFRJepYz qj/jmNz2VR+9fK+5oQV9IlBRzc+XKfujUNBRo0t6BxJU+wFHro3K7KsOYN2qnqQIcf4H NgTUlibzF208sUft6/4p/XCRN54tIhQ5D3TylNR+BYCiLms4uxPNfhLfUTbZDm5Sfh1T NBzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=axQCngYY9AV/f0N9i8xbrCWSUn9w+4io0x7Zf0Lif6w=; b=bKGgIiuskopQDFBU8KfryT6Tu01at74OEdZRCFGmvGkv9cZaTfd9F1T5lZAybqBA/M ptiFVAhV4rpxMuoZ6R9ALBcAQIG22ia/34xOk/NqZ8I1swsgcUJ+TEUcm145tU9hoK5u jNikHkRtsi0eTIwExGuuAF2Xjva8MdN4IOlyN3YPgPrAX/aSFixs5J31sAizZM2BryI9 DHVLMxdYkKY8f43dhTJFFYbmhbb7t3QK/fyM0YIzJj7FxibElf4MEucOxU3EkLC2Gjcc QPueVhvOBTM5ndLIk2kqgz4WnzJdKmHDj1ctkvc7YBDTUSF300yid73jpHl28WzBBlOm ZdtA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r14si4801517ejs.548.2020.05.28.17.11.57; Thu, 28 May 2020 17:12:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437860AbgE2AHh (ORCPT + 99 others); Thu, 28 May 2020 20:07:37 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:57510 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437671AbgE2AHg (ORCPT ); Thu, 28 May 2020 20:07:36 -0400 Received: from fsav403.sakura.ne.jp (fsav403.sakura.ne.jp [133.242.250.102]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 04T07WfL052160; Fri, 29 May 2020 09:07:32 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav403.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav403.sakura.ne.jp); Fri, 29 May 2020 09:07:32 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav403.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 04T07WeR052144 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2020 09:07:32 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() To: Linus Torvalds Cc: Petr Mladek , Andrew Morton , Linux Kernel Mailing List , Dmitry Vyukov , Ondrej Mosnacek , Sergey Senozhatsky , Steven Rostedt References: <20200528065603.3596-1-penguin-kernel@I-love.SAKURA.ne.jp> <20200528110646.GC11286@linux-b0ei> From: Tetsuo Handa Message-ID: <13b0a475-e70e-c490-d34d-0c7a34facf7c@i-love.sakura.ne.jp> Date: Fri, 29 May 2020 09:07:32 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/05/29 4:50, Linus Torvalds wrote: > On Thu, May 28, 2020 at 8:17 AM Tetsuo Handa > 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 > 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.