Re: [PATCHv13 00/28] Request API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Thu,  3 May 2018 16:52:50 +0200
Hans Verkuil <hverkuil@xxxxxxxxx> escreveu:

> From: Hans Verkuil <hans.verkuil@xxxxxxxxx>

> Regarding locking:
> 
> There are two request locks used: req_queue_mutex (part of media_device)
> ensures high-level serialization of queueing/reiniting and canceling
> requests. It serializes STREAMON/OFF, TRY/S_EXT_CTRLS, close() and
> MEDIA_REQUEST_IOC_QUEUE. This is the top-level lock and should be taken
> before any others.

Why it doesn't serialize poll()? 

> The lock spin_lock in struct media_request protects that structure and
> should be held for a short time only.
> 
> Note that VIDIOC_QBUF does not take this mutex: when
> a buffer is queued for a request it will add it to the
> request by calling media_request_object_bind(), and that returns an
> error if the request is in the wrong state. It is serialized via the
> spin_lock which in this specific case is sufficient.

It looks weird that some syscalls are not serialized. By not having
poll() and VIDIOC_QBUF serialized, I'm wandering if playing with
them and close() on separate threads won't cause bad locking. 

Thanks,
Mauro



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux