From: Greg KH <gregkh@linuxfoundation.org>
To: thomas.haemmerle@wolfvision.net
Cc: laurent.pinchart@ideasonboard.com, balbi@kernel.org,
linux-usb@vger.kernel.org, m.tretter@pengutronix.de,
linux-media@vger.kernel.org
Subject: Re: [PATCH v2] usb: gadget: uvc: fix multiple opens
Date: Tue, 10 Nov 2020 09:40:51 +0100 [thread overview]
Message-ID: <X6pSExWwSoHeSldW@kroah.com> (raw)
In-Reply-To: <20201110082504.26134-1-thomas.haemmerle@wolfvision.net>
On Tue, Nov 10, 2020 at 09:25:04AM +0100, thomas.haemmerle@wolfvision.net wrote:
> From: Thomas Haemmerle <thomas.haemmerle@wolfvision.net>
>
> Currently, the UVC function is activated when open on the corresponding
> v4l2 device is called.
> On another open the activation of the function fails since the
> deactivation counter in `usb_function_activate` equals 0. However the
> error is not returned to userspace since the open of the v4l2 device is
> successful.
>
> On a close the function is deactivated (since deactivation counter still
> equals 0) and the video is disabled in `uvc_v4l2_release`, although
> another process potentially is streaming.
>
> Move activation of UVC function to subscription on UVC_EVENT_SETUP and
> keep track of the number of subscribers (limited to 1) because there we
> can guarantee for a userspace program utilizing UVC.
> Extend the `struct uvc_file_handle` with member `bool connected` to tag
> it for a deactivation of the function.
>
> With this a process is able to check capabilities of the v4l2 device
> without deactivating the function for another process actually using the
> device for UVC streaming.
>
> Signed-off-by: Thomas Haemmerle <thomas.haemmerle@wolfvision.net>
> ---
> v2:
> - fix deadlock in `uvc_v4l2_unsubscribe_event()` (mutex is already
> locked in v4l2-core) introduced in v1
> - lock mutex in `uvc_v4l2_release()` to suppress ioctls and protect
> connected
>
> drivers/usb/gadget/function/uvc.h | 2 +
> drivers/usb/gadget/function/uvc_v4l2.c | 56 +++++++++++++++++++++-----
> 2 files changed, 48 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/uvc.h b/drivers/usb/gadget/function/uvc.h
> index 73da4f9a8d4c..0d0bcbffc8fd 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -117,6 +117,7 @@ struct uvc_device {
> enum uvc_state state;
> struct usb_function func;
> struct uvc_video video;
> + unsigned int connections;
>
> /* Descriptors */
> struct {
> @@ -147,6 +148,7 @@ static inline struct uvc_device *to_uvc(struct usb_function *f)
> struct uvc_file_handle {
> struct v4l2_fh vfh;
> struct uvc_video *device;
> + bool connected;
What protects these two fields you are adding?
> };
>
> #define to_uvc_file_handle(handle) \
> diff --git a/drivers/usb/gadget/function/uvc_v4l2.c b/drivers/usb/gadget/function/uvc_v4l2.c
> index 67922b1355e6..aee4888e17b1 100644
> --- a/drivers/usb/gadget/function/uvc_v4l2.c
> +++ b/drivers/usb/gadget/function/uvc_v4l2.c
> @@ -228,17 +228,57 @@ static int
> uvc_v4l2_subscribe_event(struct v4l2_fh *fh,
> const struct v4l2_event_subscription *sub)
> {
> + struct uvc_device *uvc = video_get_drvdata(fh->vdev);
> + struct uvc_file_handle *handle = to_uvc_file_handle(fh);
> + int ret;
> +
> if (sub->type < UVC_EVENT_FIRST || sub->type > UVC_EVENT_LAST)
> return -EINVAL;
>
> - return v4l2_event_subscribe(fh, sub, 2, NULL);
> + if ((sub->type == UVC_EVENT_SETUP) && (uvc->connections >= 1))
> + return -EBUSY;
Are you sure you can't handle more than one connection?
If so, why is it an integer and not just a boolean?
And what prevents the value from changing right after you test it here?
> +
> + ret = v4l2_event_subscribe(fh, sub, 2, NULL);
> + if (ret < 0)
> + return ret;
> +
> + if (sub->type == UVC_EVENT_SETUP) {
> + uvc->connections++;
> + handle->connected = true;
> + uvc_function_connect(uvc);
> + }
> +
> + return 0;
> +}
> +
> +static void uvc_v4l2_disable(struct uvc_device *uvc)
> +{
> + if (--uvc->connections)
> + return;
> +
What prevents "connections" from changing right after testing it here?
thanks,
greg k-h
next prev parent reply other threads:[~2020-11-10 8:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 10:31 [PATCH] usb: gadget: uvc: fix multiple opens thomas.haemmerle
2020-11-05 10:37 ` Greg KH
2020-11-09 8:59 ` [PATCH v2] " thomas.haemmerle
2020-11-10 8:25 ` thomas.haemmerle
2020-11-10 8:40 ` Greg KH [this message]
2020-11-10 9:56 ` Thomas Hämmerle
2020-11-10 10:06 ` Greg KH
2020-11-10 14:30 ` [PATCH v3] " thomas.haemmerle
2020-11-13 13:36 ` Greg KH
2020-11-16 15:48 ` Laurent Pinchart
2020-11-21 12:50 ` Thomas Hämmerle
2020-12-01 19:27 ` [PATCH v4] " Thomas Haemmerle
2020-12-07 8:53 ` Michael Tretter
2021-01-15 12:55 ` Michael Tretter
2021-01-15 13:09 ` Felipe Balbi
2021-02-11 15:04 ` Michael Tretter
2021-10-03 20:13 ` [RESEND PATCH " Michael Grzeschik
2021-10-04 23:53 ` Laurent Pinchart
2021-10-05 10:59 ` Greg KH
2021-10-05 11:06 ` Felipe Balbi
2021-10-05 11:37 ` Greg KH
2021-10-04 23:55 ` [PATCH v3] " Laurent Pinchart
2020-11-10 10:31 ` [PATCH v2] " Hans Verkuil
2020-11-10 11:53 ` Thomas Hämmerle
2020-11-10 14:43 ` Hans Verkuil
2020-11-10 15:10 ` Thomas Hämmerle
2020-11-10 15:36 ` Hans Verkuil
2020-11-10 15:50 ` Thomas Hämmerle
2020-11-10 16:01 ` Hans Verkuil
2020-11-16 15:31 ` Laurent Pinchart
2020-11-16 15:48 ` Hans Verkuil
2020-11-16 15:50 ` Laurent Pinchart
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=X6pSExWwSoHeSldW@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=balbi@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=thomas.haemmerle@wolfvision.net \
/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.