All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Dmitry Vyukov <dvyukov@google.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>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: usb/core: warning in usb_create_ep_devs/sysfs_create_dir_ns
Date: Mon, 12 Dec 2016 17:04:32 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1612121658150.1502-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1612121641400.1502-100000@iolanthe.rowland.org>

On Mon, 12 Dec 2016, Alan Stern wrote:

> On Mon, 12 Dec 2016, Dmitry Vyukov wrote:
> 
> > On Mon, Dec 12, 2016 at 10:05 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > On Mon, 12 Dec 2016, Andrey Konovalov wrote:
> > >
> > >> Hi!
> > >>
> > >> While running the syzkaller fuzzer I've got the following error report.
> > >>
> > >> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dev 2).
> > >>
> > >> WARNING: CPU: 2 PID: 865 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x8a/0xa0
> > >> gadgetfs: disconnected
> > >> sysfs: cannot create duplicate filename
> > >> '/devices/platform/dummy_hcd.0/usb2/2-1/2-1:64.0/ep_05'
> > >> Kernel panic - not syncing: panic_on_warn set ...
> > >
> > > I suppose we could check for USB devices that claim to have two
> > > endpoints with the same address.  But is it really worthwhile?  A
> > > kernel warning isn't so bad when you're dealing with buggy device
> > > firmware.
> > 
> > We need a clear distinction between what is a bug in kernel source
> > code and what is incorrect user-space code. Otherwise no automated
> > testing is possible. WARNING means bug in kernel source code.
> 
> I don't necessarily agree with that.  Is it documented anywhere?
> 
> >  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?

Alan Stern

  reply	other threads:[~2016-12-12 22:04 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 [this message]
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
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=Pine.LNX.4.44L0.1612121658150.1502-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@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.