Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp342648ybm; Fri, 29 May 2020 01:20:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyR69JRhVvIr2v1s9Bq0LmjKxlei5xk2YYrh3SFMcKTH3EKYmChoYrbJZHCzYqEXhdmHjD X-Received: by 2002:aa7:d999:: with SMTP id u25mr7153493eds.339.1590740411261; Fri, 29 May 2020 01:20:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590740411; cv=none; d=google.com; s=arc-20160816; b=g4JCmBAdzKDklE4l2MzP5GnY8WfrkOqLIzppW4QMKiZekp1PMcjdyhK+vdtVPeJGIl qjgpQKiUB2xmXZ3OIOYJwnaEUjCmTrG1eJguChky4HpHg41+0HfwgdrZXgGFK/cF/iOX N5VsoAStwh5lZG+3M3owNciRHCRRdyy59PIWwwobU+swPsHv3INHUWl4KP9RSo/T5uD+ 0y944SwNhZ4T+p6o433TZloDqKR4vhMMrf6ulKBh+OSuEaOoGtVtHFXBmgH291QVOp6Q RefWpEY6EiJyNMsIW/LZnvSj7GyC6gPLH60k1/DcUCYnW5ZU3BDygADfApG2P62u1+vw i0zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=WYGCmasjmLM6ObhXTo93EOYtWyqiSae+DIW/q1J2fTU=; b=h59qwmvCG4y9xQHzMhaDZniA1LZh/MNsn2ub66wtiqfB2vjEdiulecHIEWLrU9FnWB Po743WX3NQztlZWE66qfl1p3WJRLhDDD/DQjJTXhCZArVQ9zP+jSX0O7lqrmuFoPiAa5 pLkNZYuQdass7ZWSR7ftW9S7Y47SSxdy3EG3jss6e5Nx6BlzE6/YWYAZdvfbR/hIz+14 pjq2/Aff1wWW9QB+KSA+Q7kS/+KviWzHfOlXrh8WFL5iK8jvtfOL91X8SJ+xKs5Z8Z1o Byn5WAHC1VeoQJJoQoXkOOlaDW9YuLyvMSouIOJTWoIJOAhgGLXuCKsayxwtKfPP2Rqy QF8Q== 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 jx4si4915859ejb.216.2020.05.29.01.19.48; Fri, 29 May 2020 01:20:11 -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 S1725836AbgE2IRw (ORCPT + 99 others); Fri, 29 May 2020 04:17:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:57912 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725562AbgE2IRw (ORCPT ); Fri, 29 May 2020 04:17:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DA554AB5C; Fri, 29 May 2020 08:17:49 +0000 (UTC) Date: Fri, 29 May 2020 10:17:48 +0200 From: Petr Mladek To: Linus Torvalds Cc: Tetsuo Handa , Andrew Morton , Linux Kernel Mailing List , Dmitry Vyukov , Ondrej Mosnacek , Sergey Senozhatsky , Steven Rostedt Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() Message-ID: <20200529081748.GC27273@linux-b0ei> References: <20200528065603.3596-1-penguin-kernel@I-love.SAKURA.ne.jp> <20200528110646.GC11286@linux-b0ei> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2020-05-28 12:50:35, 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. > > 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"? I am afraid that many of them could not be normal options. They change or break some behavior that is necessary by seriously used system. > I've complained about this whole thing before. I'm getting really fed > up with this whole concept of "magic crazy config options". Just to make my role clear in this saga. I am focused on the change of pr_debug() behavior. I do _not_ believe that it is worth it. But I wanted to give fuzzer guys a chance to get some data. This is why I offered to push hacky patch into linux-next via printk tree to get fuzzers fed. Such a patch would change the behavior only for the fuzzer (with the crazy config enabled) and it would be there only for a limited time. I personally do _not_ have a good feeling about having such hacks in upstream kernel. But I do not feel in position to decide about it. I wanted to solve this question later if there would have been anything to upstream. I am _not_ going to push any twists, in the current form, upstream via printk tree. Best Regards, Petr