All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: syzkaller <syzkaller@googlegroups.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	USB list <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Kostya Serebryany <kcc@google.com>
Subject: Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns
Date: Tue, 13 Dec 2016 19:44:34 +0100	[thread overview]
Message-ID: <CACT4Y+ZhYw0PEoJhAznhq30CV5mp4NpLVQb5VVY6fNTGgUz4MA@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1612131320350.1533-100000@iolanthe.rowland.org>

On Tue, Dec 13, 2016 at 7:38 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 13 Dec 2016, Dmitry Vyukov wrote:
>
>> On Tue, Dec 13, 2016 at 4:52 PM, Alan Stern <stern@rowland.harvard.edu> 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

  reply	other threads:[~2016-12-13 18:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-12 20:48 usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns Andrey Konovalov
2016-12-12 21:05 ` Alan Stern
2016-12-12 21:16   ` Dmitry Vyukov
2016-12-12 21:48     ` Alan Stern
2016-12-12 22:04       ` Alan Stern
2016-12-13 15:07         ` Dmitry Vyukov
2016-12-13 15:52           ` Alan Stern
2016-12-13 16:23             ` Dmitry Vyukov
2016-12-13 18:38               ` Alan Stern
2016-12-13 18:44                 ` Dmitry Vyukov [this message]
2016-12-13 20:09                   ` Alan Stern
2016-12-13 20:32                     ` Dmitry Vyukov
2016-12-12 21:49     ` Greg Kroah-Hartman
2016-12-16 18:01 ` Alan Stern
2016-12-17 17:12   ` Andrey Konovalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+ZhYw0PEoJhAznhq30CV5mp4NpLVQb5VVY6fNTGgUz4MA@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=andreyknvl@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kcc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.