Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1014423ybh; Thu, 12 Mar 2020 15:30:55 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtlcrDr3aM0lFvBRghzI0kd73oBQHqQJRa8hmujL2xZDPSNmIp5hy5/TEGQ/ofjKThLciLF X-Received: by 2002:aca:600b:: with SMTP id u11mr4612440oib.6.1584052254915; Thu, 12 Mar 2020 15:30:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584052254; cv=none; d=google.com; s=arc-20160816; b=Yso4gHe4toPY/pOfhKigK7gKNc4/Mwc734CuS+o+GwHETjhj0rWy2j8eooy+fGWkDL uJI1w8x65sfr0iec7wdN8WdPk6ql3/bYQ+hSrEBlL1T1C11jAJEThoDUwC/DuDU7CgRb EhJ/BQdM6pB1iHg3J3SeBr9g6nS9MJDkiQaHC6fuc62398IZ25QMNBqmBigRifDSJIXb yYV7G0x0tqCnk6NeECqg6jWTuRG296wWB0kcQ1qZYRRYP4N5US8u6JdIxFdKDhM4E848 uS3Tw6VKx3FN3z3xBbWdLgIuc1awbxYVWdFXQkY9bGzdSjkQn5ZNGZousCNTy2UliN+e heRw== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=tPiuBuAmHBo7ITdw3gT7LYZD7XideE/buowOGqAQBR8=; b=eueTRrHTD6nextCEfEqR0gb7fCD6f31ncD/0sPC+rWqdJMAB/bf9mTZmeQ3fj2CrTu rbUZkiCtkdBeXjB7lehuT6au2peTzs0etR2rQ9kfLEoQHxDjkVWmTkx7oltiJOm/OgaW hWauC7DBgMMKiQir9MxQfaqcPCZRpob/E3+qjnZiNgJnC69ZvRaWijc7Lni3EdP1A6BM +4xbIyaG9X7VPO14tpmhcCfF89tTkBd91Z8+kyn4erJZceb++EBcucJrET5/NenmBVza 2Rn3PzR9xiALysTl+xZ7bR+eSyVO2vltBYjppLgTo754OHubLR3ngf6qhYhaO6LuZmRT PaHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l8si3244920oii.249.2020.03.12.15.30.42; Thu, 12 Mar 2020 15:30:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726863AbgCLW3j (ORCPT + 99 others); Thu, 12 Mar 2020 18:29:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:52138 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbgCLW3j (ORCPT ); Thu, 12 Mar 2020 18:29:39 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4920120637; Thu, 12 Mar 2020 22:29:37 +0000 (UTC) Date: Thu, 12 Mar 2020 18:29:35 -0400 From: Steven Rostedt To: Tetsuo Handa Cc: Dmitry Vyukov , Jiri Slaby , Greg Kroah-Hartman , Andrew Morton , Matthew Garrett , Andi Kleen , "Theodore Y . Ts'o" , Alexander Viro , Petr Mladek , Sergey Senozhatsky , Arnd Bergmann , Linus Torvalds , LKML , Peter Zijlstra Subject: Re: [PATCH v2] Add kernel config option for fuzz testing. Message-ID: <20200312182935.70ed6516@gandalf.local.home> In-Reply-To: <7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp> References: <20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp> <6f2e27de-c820-7de3-447d-cd9f7c650add@suse.com> <20200308065258.GE3983392@kroah.com> <3e9f47f7-a6c1-7cec-a84f-e621ae5426be@suse.com> <20200311101115.53139149@gandalf.local.home> <7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Mar 2020 06:59:22 +0900 Tetsuo Handa wrote: > On 2020/03/13 4:23, Dmitry Vyukov wrote: > >> Or teach the fuzz tool not to do specific bad things. > > > > We do some of this. > > But generally it's impossible for anything that involves memory > > indirections, or depends on the exact type of fd (e.g. all ioctl's), > > etc. Boils down to halting problem and ability to predict exact > > behavior of arbitrary programs. > > I would like to enable changes like below only if CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y . > > Since TASK_RUNNING threads are not always running on CPUs (in syzbot, the kernel is > tested on a VM with only 2 CPUs, which means that many threads are simply waiting for > CPU time to be assigned), dumping locks held by all threads gives us more clue when > e.g. khungtask fired. But since lockdep_print_held_locks() is racy, I assume that > this change won't be accepted unless CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y . > > Also, for another example, limit number of memory pages /dev/ion driver can consume only if > CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y ( https://github.com/google/syzkaller/issues/1267 ), > for limiting number of memory pages is a user-visible change while we need to avoid false > alarms caused by consuming all memory pages. > > In other words, while majority of things CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y would > do "disable this", there would be a few "enable this" and "change this". I still fear that people will just disable large sections. I've seen this before. Developers take the easy way out, and when someone adds a new feature that may be dangerous, they will just say "oh turn off fuzzing" and be done with it. As Linus likes to say, when you need to make changes to the kernel to test it, you are no longer testing production kernels. > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 32406ef0d6a2..1bc7878768fc 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -695,6 +695,7 @@ static void print_lock(struct held_lock *hlock) > static void lockdep_print_held_locks(struct task_struct *p) > { > int i, depth = READ_ONCE(p->lockdep_depth); > + bool unreliable; > > if (!depth) > printk("no locks held by %s/%d.\n", p->comm, task_pid_nr(p)); > @@ -705,10 +706,12 @@ static void lockdep_print_held_locks(struct task_struct *p) > * It's not reliable to print a task's held locks if it's not sleeping > * and it's not the current task. > */ > - if (p->state == TASK_RUNNING && p != current) > - return; > + unreliable = p->state == TASK_RUNNING && p != current; > for (i = 0; i < depth; i++) { > - printk(" #%d: ", i); > + if (unreliable) > + printk(" #%d?: ", i); > + else > + printk(" #%d: ", i); Have you tried submitting this? Has Peter nacked it? -- Steve > print_lock(p->held_locks + i); > } > }