Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp541666ybm; Fri, 29 May 2020 06:29:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzTOQfM7a/3nyLqx17p4RP/jZLG9pqnyYAAev6rR0ljvDHG13F2RXpiOehcDCHIVjwsxPa8 X-Received: by 2002:a17:907:9495:: with SMTP id dm21mr7487886ejc.357.1590758988687; Fri, 29 May 2020 06:29:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590758988; cv=none; d=google.com; s=arc-20160816; b=NvnmTUXN8BpHj6uCwrfOblcIGdM86190EDZzXvn4IOOS+ou1N1LJU3jaj1pkEJcn5a Bh4dGSFCJTvww90zRBda0o3YVWswkjapBPQhJiFOanuWjTvLkqvyv9QMTnBClGc6flF2 9p9QrO06wHSbE05LnIueBQIc1GM0ERvbL+hs1nbd3M4G1tpo7dIhWBdpEQ39w7Hce3dv tn+PC0p4Fwaz6d7xQP40V1Ca5UXzo8QAn8Qy2roY5etlWxWQ8YqaSwv5SxywruNcVuET 7VwqUihwPkuqd41pqJljH49AxW/ZYTQXQcwphrsEs5T7PmnpDPdv169LaAECNFN+sHqp UcRw== 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:references:cc:to:from:subject; bh=9HHkBhPmTwBiYdxd+75aHXeu/HHK7Do7gr5QdDBZRZM=; b=LsmpZqyJivnf2F/ufK55Ifn98ifKmGWOJeMTN/QKTsNn4pRHw6lPr9YvjsfQE61lWt bdbDBtEGahiCjctkag6EmtkhL5NyARH0SQwYqLPv6aouJFqhAweET7UrMoJXgxjwnziX UYaQh7rz6m5tZJDkY4EIo2812rUnRv9w647DxlOgVZg+w0UO+jqtFET/k2BvMT/slCyn e2LxVvY5doJFH6suY3D1BwuKfF5LQ2oCWvkYmoI62bMxCx5xHCIqzoBUUEIY5G+hyu6b 1C+EUHuCG8RidINoiZlGtaLceDHv39U/yrXt8dyhU8bLrJgs8FBEIp7ZROeyauECvJYI +Rng== 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 dx17si5476788ejb.467.2020.05.29.06.29.24; Fri, 29 May 2020 06:29:48 -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 S1726923AbgE2N1B (ORCPT + 99 others); Fri, 29 May 2020 09:27:01 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:63047 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726792AbgE2N06 (ORCPT ); Fri, 29 May 2020 09:26:58 -0400 Received: from fsav402.sakura.ne.jp (fsav402.sakura.ne.jp [133.242.250.101]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 04TDQuDh004920; Fri, 29 May 2020 22:26:56 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav402.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav402.sakura.ne.jp); Fri, 29 May 2020 22:26:56 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav402.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 04TDQoUw004862 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 May 2020 22:26:55 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf() From: Tetsuo Handa To: Dmitry Vyukov , syzkaller Cc: Linus Torvalds , Petr Mladek , Andrew Morton , Linux Kernel Mailing List , Ondrej Mosnacek , Sergey Senozhatsky , Steven Rostedt References: <20200528065603.3596-1-penguin-kernel@I-love.SAKURA.ne.jp> <20200528110646.GC11286@linux-b0ei> <13b0a475-e70e-c490-d34d-0c7a34facf7c@i-love.sakura.ne.jp> <6116ed2e-cee1-d82f-6b68-ddb1bbb6abe2@i-love.sakura.ne.jp> <19d377d3-8037-8090-0f99-447f72cc1d8c@i-love.sakura.ne.jp> Message-ID: <38df9737-3c04-dca2-0df4-115a9c1634e5@i-love.sakura.ne.jp> Date: Fri, 29 May 2020 22:26:48 +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: <19d377d3-8037-8090-0f99-447f72cc1d8c@i-love.sakura.ne.jp> 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 Hello, Dmitry. Linus is asking me to avoid build-time switching based on kernel config options, and is suggesting me to use boot-time switching based on boot-config file feature (which is available since 5.6). I have several concerns about use of boot-config file feature in syzkaller. (1) To use boot-config file, syzkaller will need to add "bootconfig" option to the kernel command line. This will be doable by patching https://github.com/google/syzkaller/tree/master/dashboard/config/ *.cmdline files. (2) The boot-config file is embedded into initramfs file. Since syzkaller builds kernels with almost-allyesconfig, booting syzkaller kernels do not require initramfs for loading kernel modules needed for mounting the root partition. In fact, according to "unexpected kernel reboot" report which contains boot messages, I can't find "Unpacking initramfs..." message. It seems that syzkaller kernels do not use initramfs file. Is it possible for syzkaller to enforce performing steps for creating an initramfs, embedding the boot-config file ( https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html#boot-kernel-with-a-boot-config), and loading that initramfs whenever booting the syzkaller kernels? By the way, I do worry that people forget to perform these steps when they do their tests without asking syzbot... (3) Since syzkaller keeps track of "kernel tree", "commit of the kernel tree", and "commit of the syzkaller tree" in order to guarantee reproducibility, it would be possible to identify the "your-config" file used for tools/bootconfig/bootconfig command. But since "#syz test" command currently accepts only "kernel tree" and "commit of the kernel tree" arguments, we might fail to use intended "your-config" file when doing reproducibility test. Can syzbot solve this concern? (4) Of course, "your-config" file would not change so frequently, but "#syz test" command relies on external file in "syzkaller tree" makes it impossible to try different configuration when I have to ask syzbot to test. (Since I don't have hardware which syzbot is reporting problems, I have to ask syzbot when I can't reproduce the problem in my environment.) https://syzkaller.appspot.com/text?tag=Patch&x=135f254a100000 is an example of need to enforce CONFIG_DEBUG_INFO_BTF=n in order to workaround build failure during "#syz test" command. If we bring "which twist options should be enabled" to an external boot-config file, I can't ask syzbot to try different twist options (except directly patching the kernel source which handles "which twist options should be enabled"). Can syzbot solve this concern? (5) Anything else?