[Linux-uvc-devel] Thread safety of ioctls
laurent.pinchart at skynet.be
Tue Jun 24 00:33:40 CEST 2008
On Monday 23 June 2008, Gregor Jasny wrote:
> in our video conference application the grabbing (QBUF, DQBUF) is done
> in a separate thread. The main thread is responsible for the user
> interface and queries the controls, input and current standard values
> from time to time.
> With the latest uvc driver (r217) and vanilla Linux 18.104.22.168 I've
> noticed the strange behavior that the grabbing thread hangs in the DQBUF
> ioctl. If I remove the control queries from the gui thread everything is
> working fine. After the first hang of the driver, even luvcview hangs at
> the buffer operation.
> With the bttv driver everything works fine. I'll test vivi and pwc
> driver later.
> My systems are a i686 and one amd64 system with one Logitech 9000 and
> one Microsoft NX-6000. I've tried to create a simple testcase, but
> suprinsingly this testcase works fine.
> Can I enable more logging than setting the trace parameter to 0xfff?
No without adding more printk's to the driver, which I encourage you to do.
> Have you any idea what went wrong here?
Not really. The ioctl handler is protected by the big kernel lock, so ioctls
are currently not reentrant.
Could you give more information about the hardware you are using (webcam, SMP
system) ? Please report kernel log message printed by the UVC driver as well.
> Is the V4L2-API designed to be thread safe?
There is no mention of thread safety in the V4L2 spec, so one can always argue
that thread safety is not required for V4L2 drivers :-)
Most drivers are probably not designed with thread safety in mind, and I'm
pretty sure lots of race conditions still lie in the depth of V4L(2) drivers.
In the long term all those bugs should be fixed, and drivers should support
multi-threaded applications without crashing or misbehaving.
More information about the Linux-uvc-devel