Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934542AbcLMSo7 (ORCPT ); Tue, 13 Dec 2016 13:44:59 -0500 Received: from mail-lf0-f48.google.com ([209.85.215.48]:33780 "EHLO mail-lf0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932250AbcLMSo5 (ORCPT ); Tue, 13 Dec 2016 13:44:57 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Dmitry Vyukov Date: Tue, 13 Dec 2016 19:44:34 +0100 Message-ID: Subject: Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns To: syzkaller Cc: Andrey Konovalov , Greg Kroah-Hartman , USB list , LKML , Kostya Serebryany Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1822 Lines: 44 On Tue, Dec 13, 2016 at 7:38 PM, Alan Stern wrote: > On Tue, 13 Dec 2016, Dmitry Vyukov wrote: > >> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern wrote: >> > On Tue, 13 Dec 2016, Dmitry Vyukov wrote: >> > >> >> >> > If it is >> >> >> > not a bug in kernel source code, then it must not produce a WARNING. >> >> > >> >> > What about a memory allocation failure? The memory management part of >> >> > the kernel produces a WARNING message if an allocation fails and the >> >> > caller did not specify __GFP_NOWARN. >> >> > >> >> > There is no way for a driver to guarantee that a memory allocation >> >> > request will succeed -- failure is always an option. But obviously >> >> > memory allocation failures are not bugs in the kernel. >> >> > >> >> > Are you saying that mm/page_alloc.c:warn_alloc() should produce >> >> > something other than a WARNING? >> >> >> >> >> >> The main thing I am saying is that we absolutely need a way for a >> >> human or a computer program to be able to determine if there is >> >> anything wrong with kernel or not. >> > Doesn't it also produce a WARNING under other circumstances? >> >> No. >> >> OOM is not a WARNING and is easily distinguishable from BUG/WARNING. > >> Memory allocator does not print WARNINGs on allocation failures. > > Do you count dev_warn the same as WARN or WARN_ON? What about dev_WARN > or pr_warn() or printk(KERN_WARNING...)? Maybe we're not talking about > the same messages. > > The USB subsystem has got tons of dev_warn() and dev_err() calls. > Relatively few (if any) of them are for kernel bugs. I grep for "WARNING:". It is not possible to understand what function printed messages on console. Here are my current regexps: https://github.com/google/syzkaller/blob/master/report/report.go#L29