Re: uvcvideo logging kernel warnings on device disconnect

[Greg KH <greg@kroah.com>]

On Sun, Apr 30, 2017 at 06:19:59PM +0200, Greg KH wrote:
> On Sun, Apr 16, 2017 at 02:11:31PM +0300, Laurent Pinchart wrote:
> > Hi Greg,
> > 
> > On Wednesday 21 Dec 2016 10:59:54 Greg KH wrote:
> > > On Tue, Dec 20, 2016 at 11:19:23AM +0000, Dave Stevenson wrote:
> > > > On 09/12/16 09:43, Greg KH wrote:
> > > >> On Fri, Dec 09, 2016 at 11:14:41AM +0200, Laurent Pinchart wrote:
> > > >>> On Friday 09 Dec 2016 10:11:13 Greg KH wrote:
> > > >>>> On Fri, Dec 09, 2016 at 10:59:24AM +0200, Laurent Pinchart wrote:
> > > >>>>> On Friday 09 Dec 2016 08:25:52 Greg KH wrote:
> > > >>>>>> On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> > > >>>>>>> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> > > >>>>>>>> Hi All.
> > > >>>>>>>> 
> > > >>>>>>>> I'm working with a USB webcam which has been seen to
> > > >>>>>>>> spontaneously disconnect when in use. That's a separate
> > > >>>>>>>> issue, but when it does it throws a load of warnings into
> > > >>>>>>>> the kernel log if there is a file handle on the device open
> > > >>>>>>>> at the time, even if not streaming.
> > > >>>>>>>> 
> > > >>>>>>>> I've reproduced this with a generic Logitech C270 webcam on:
> > > >>>>>>>> - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the
> > > >>>>>>>> latest media tree from linuxtv.org
> > > >>>>>>>> - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> > > >>>>>>>> - an old 3.10.x tree on an embedded device.
> > > >>>>>>>> 
> > > >>>>>>>> To reproduce:
> > > >>>>>>>> - connect USB webcam.
> > > >>>>>>>> - run a simple app that opens /dev/videoX, sleeps for a
> > > >>>>>>>> while, and then closes the handle.
> > > >>>>>>>> - disconnect the webcam whilst the app is running.
> > > >>>>>>>> - read kernel logs - observe warnings. We get the disconnect
> > > >>>>>>>> logged as it occurs, but the warnings all occur when the
> > > >>>>>>>> file descriptor is closed. (A copy of the logs from my
> > > >>>>>>>> Ubuntu 14.04 machine are below).
> > > >>>>>>>> 
> > > >>>>>>>> I can fully appreciate that the open file descriptor is
> > > >>>>>>>> holding references to a now invalid device, but is there a
> > > >>>>>>>> way to avoid them? Or do we really not care and have to put
> > > >>>>>>>> up with the log noise when doing such silly things?
> > > >>>>>>> 
> > > >>>>>>> This is a known problem, caused by the driver core trying to
> > > >>>>>>> remove the same sysfs attributes group twice.
> > > >>>>>> 
> > > >>>>>> Ick, not good.
> > > >>>>>> 
> > > >>>>>>> The group is first removed when the USB device is
> > > >>>>>>> disconnected. The input device and media device created by the
> > > >>>>>>> uvcvideo driver are children of the USB interface device,
> > > >>>>>>> which is deleted from the system when the camera is unplugged.
> > > >>>>>>> Due to the parent-child relationship, all sysfs attribute
> > > >>>>>>> groups of the children are removed.
> > > >>>>>> 
> > > >>>>>> Wait, why is the USB device being removed from sysfs at this
> > > >>>>>> point, didn't the input and media subsystems grab a reference to
> > > >>>>>> it so that it does not disappear just yet?
> > > >>>>> 
> > > >>>>> References are taken in uvc_prove():
> > > >>>>>         dev->udev = usb_get_dev(udev);
> > > >>>>>         dev->intf = usb_get_intf(intf);
> > > >>>> 
> > > >>>> s/uvc_prove/uvc_probe/ ?  :)
> > > >>> 
> > > >>> Oops :-)
> > > >>> 
> > > >>>>> and released in uvc_delete(), called when the last video device
> > > >>>>> node is closed. This prevents the device from being released
> > > >>>>> (freed), but device_del() is synchronous to device unplug as far
> > > >>>>> as I understand.
> > > >>>> 
> > > >>>> Ok, good, that means the UVC driver is doing the right thing here.
> > > >>>> 
> > > >>>> But the sysfs files should only be attempted to be removed by the
> > > >>>> driver core once, when the device is removed from sysfs, not twice,
> > > >>>> which is really odd.
> > > >>>> 
> > > >>>> Is there a copy of the "simple app that grabs the device node"
> > > >>>> anywhere so that I can test it out here with my USB camera device to
> > > >>>> try to track down where the problem is?
> > > >>> 
> > > >>> Sure. The easiest way is to grab http://git.ideasonboard.org/yavta.git
> > > >>> and run
> > > >>> 
> > > >>> yavta -c /dev/video0
> > > >>> 
> > > >>> (your mileage may vary if you have other video devices)
> > > >> 
> > > >> I'll point it at the correct device, /dev/video0 is built into this
> > > >> laptop and can't be physically removed :)
> > > >> 
> > > >>> While the application is running, unplug the webcam, and then
> > > >>> terminate the application with ctrl-C.
> > > >> 
> > > >> Ok, will try this out this afternoon and let you know how it goes.
> > > > 
> > > > I hate to pester, but wondered if you had found anything obvious.
> > > > I really do appreciate you taking the time to look.
> > > 
> > > Sorry, I haven't had the chance and now will not be able to until
> > > January....
> > 
> > Did you mean January 2017 or 2018 ? :-)
> 
> Heh, sorry about this, I think David's patch should resolve this now.

Ugh, jet-lag, that should read "Daniel", my apologies.

greg k-h