Message ID | 20161129235712.29846-2-khilman@baylibre.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Hans Verkuil |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <linux-media-owner@vger.kernel.org>) id 1cBsH9-0005ay-D6; Tue, 29 Nov 2016 23:57:27 +0000 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-6) with esmtp id 1cBsH7-0002iy-3n; Wed, 30 Nov 2016 00:57:27 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754914AbcK2X5X (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Tue, 29 Nov 2016 18:57:23 -0500 Received: from mail-pf0-f174.google.com ([209.85.192.174]:35739 "EHLO mail-pf0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbcK2X5Q (ORCPT <rfc822;linux-media@vger.kernel.org>); Tue, 29 Nov 2016 18:57:16 -0500 Received: by mail-pf0-f174.google.com with SMTP id i88so34649466pfk.2 for <linux-media@vger.kernel.org>; Tue, 29 Nov 2016 15:57:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KQY5Seqr/M6hCfsYXzeqPzAURciWFUOYAcbkAozB2nQ=; b=yixB13yBD0SseJeBuqWeRKzOmRBX8Vk+OprjdzgRWyNSibOo4LdujrrkwMTl/hEoIk OJo5knrA/JXWT9d7pmnLgMd4cpooYvhkSE9vh+cbV2o4L094mIvHWevgUEve9Zf7I7c8 OKH/iXTo7VzgdIya+0xO+2rLRO+OjhAfkgx3umGu3z1jU0NfkW0CWs+A5qFstj7WuxJ+ JSf+4VBuIKV/ydbzNVKKJXGMX5WImKNC1M7g344B6P6CTOA/cYWi+ECKIKFkHgawmgYG xVb1gGE9R8MZ0WFBtVl3oBm81099uQV1AuEBMECxcMQ0/Z7EZVFfIgpx8WE1F9XR9NUl B0qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=KQY5Seqr/M6hCfsYXzeqPzAURciWFUOYAcbkAozB2nQ=; b=RYl6Ox1xk1fVcp7hZ/bl0KW+aacJqf3+XsaWAfUkFiPxvR1/rTY3dZTqMwlKTWZhsz TsSrcO5EQgXtkSfbIbhr19OH6gVFhcsPoBIdwsDYjKY1ZFu17b79N18rvSRh4uUJ8pll okXFuKbNyMANtFm/lMaQjfTvfiTh0nJ6/RMxNnKD4cQfn+n89B4mvdVj62CNmGw0sCkN ak8cqDgI7TReYTr+mLxWFaQ/ojIw8R6OfipxIbXsMLnU7m4Yv+3ayAz9XAzPYcUVNB0Z nwnY+AVCrzjc5UjXaAPq22QD8FXK3ht2rr2KjSplnW9z1TZj1+VWEtDm15jKxOzGm/3h Usxg== X-Gm-Message-State: AKaTC00KTL2GpkRdtKkV6DPfBirkggtnwViXTf7n7ATMfJV3mrPZoIAwMqF12dBO0EX+gPjy X-Received: by 10.84.216.25 with SMTP id m25mr67176438pli.117.1480463835526; Tue, 29 Nov 2016 15:57:15 -0800 (PST) Received: from localhost (c-98-203-232-209.hsd1.wa.comcast.net. [98.203.232.209]) by smtp.gmail.com with ESMTPSA id t25sm54655244pgo.9.2016.11.29.15.57.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Nov 2016 15:57:15 -0800 (PST) From: Kevin Hilman <khilman@baylibre.com> To: linux-media@vger.kernel.org Cc: Hans Verkuil <hverkuil@xs4all.nl>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Sakari Ailus <sakari.ailus@iki.fi>, linux-arm-kernel@lists.infradead.org, Sekhar Nori <nsekhar@ti.com>, Rob Herring <robh@kernel.org>, devicetree@vger.kernel.org Subject: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream Date: Tue, 29 Nov 2016 15:57:09 -0800 Message-Id: <20161129235712.29846-2-khilman@baylibre.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20161129235712.29846-1-khilman@baylibre.com> References: <20161129235712.29846-1-khilman@baylibre.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.29.235118 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DKIM_SIGNATURE 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_URI_HTTPS 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CTE 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __YOUTUBE_RCVD 0' |
Commit Message
Kevin Hilman
Nov. 29, 2016, 11:57 p.m. UTC
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 3 +++
1 file changed, 3 insertions(+)
Comments
Hi Kevin, Thank you for the patch. On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote: > Video capture subdevs may be over I2C and may sleep during xfer, so we > cannot do IRQ-disabled locking when calling the subdev. > > Signed-off-by: Kevin Hilman <khilman@baylibre.com> > --- > drivers/media/platform/davinci/vpif_capture.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/media/platform/davinci/vpif_capture.c > b/drivers/media/platform/davinci/vpif_capture.c index > 5104cc0ee40e..9f8f41c0f251 100644 > --- a/drivers/media/platform/davinci/vpif_capture.c > +++ b/drivers/media/platform/davinci/vpif_capture.c > @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq, > unsigned int count) } > } > > + spin_unlock_irqrestore(&common->irqlock, flags); > ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); > + spin_lock_irqsave(&common->irqlock, flags); I always get anxious when I see a spinlock being released randomly with an operation in the middle of a protected section. Looking at the code it looks like the spinlock is abused here. irqlock should only protect the dma_queue and should thus only be taken around the following code: spin_lock_irqsave(&common->irqlock, flags); /* Get the next frame from the buffer queue */ common->cur_frm = common->next_frm = list_entry(common->dma_queue.next, struct vpif_cap_buffer, list); /* Remove buffer from the buffer queue */ list_del(&common->cur_frm->list); spin_unlock_irqrestore(&common->irqlock, flags); The code that is currently protected by the lock in the start and stop streaming functions should be protected by a mutex instead. > + > if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) { > vpif_dbg(1, debug, "stream on failed in subdev\n"); > goto err;
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes: > Hi Kevin, > > Thank you for the patch. > > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote: >> Video capture subdevs may be over I2C and may sleep during xfer, so we >> cannot do IRQ-disabled locking when calling the subdev. >> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> >> --- >> drivers/media/platform/davinci/vpif_capture.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c index >> 5104cc0ee40e..9f8f41c0f251 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq, >> unsigned int count) } >> } >> >> + spin_unlock_irqrestore(&common->irqlock, flags); >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); >> + spin_lock_irqsave(&common->irqlock, flags); > > I always get anxious when I see a spinlock being released randomly with an > operation in the middle of a protected section. Looking at the code it looks > like the spinlock is abused here. irqlock should only protect the dma_queue > and should thus only be taken around the following code: > > spin_lock_irqsave(&common->irqlock, flags); > /* Get the next frame from the buffer queue */ > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next, > struct vpif_cap_buffer, list); > /* Remove buffer from the buffer queue */ > list_del(&common->cur_frm->list); > spin_unlock_irqrestore(&common->irqlock, flags); Yes, that looks correct. Will update. > The code that is currently protected by the lock in the start and stop > streaming functions should be protected by a mutex instead. I tried taking the mutex here, but lockdep pointed out a deadlock. I may not be fully understanding the V4L2 internals here, but it seems that the ioctl is already taking a mutex, so taking it again in start/stop streaming is a deadlock. Unless you think the locking should be nested here, it seems to me that the mutex isn't needed. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Kevin, On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote: > Laurent Pinchart writes: > > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote: > >> Video capture subdevs may be over I2C and may sleep during xfer, so we > >> cannot do IRQ-disabled locking when calling the subdev. > >> > >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> > >> --- > >> drivers/media/platform/davinci/vpif_capture.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/media/platform/davinci/vpif_capture.c > >> b/drivers/media/platform/davinci/vpif_capture.c index > >> 5104cc0ee40e..9f8f41c0f251 100644 > >> --- a/drivers/media/platform/davinci/vpif_capture.c > >> +++ b/drivers/media/platform/davinci/vpif_capture.c > >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue > >> *vq, unsigned int count) > >> } > >> } > >> > >> + spin_unlock_irqrestore(&common->irqlock, flags); > >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); > >> + spin_lock_irqsave(&common->irqlock, flags); > > > > I always get anxious when I see a spinlock being released randomly with an > > operation in the middle of a protected section. Looking at the code it > > looks like the spinlock is abused here. irqlock should only protect the > > dma_queue and should thus only be taken around the following code: > > > > spin_lock_irqsave(&common->irqlock, flags); > > /* Get the next frame from the buffer queue */ > > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next, > > struct vpif_cap_buffer, list); > > > > /* Remove buffer from the buffer queue */ > > list_del(&common->cur_frm->list); > > spin_unlock_irqrestore(&common->irqlock, flags); > > Yes, that looks correct. Will update. > > > The code that is currently protected by the lock in the start and stop > > streaming functions should be protected by a mutex instead. > > I tried taking the mutex here, but lockdep pointed out a deadlock. I > may not be fully understanding the V4L2 internals here, but it seems > that the ioctl is already taking a mutex, so taking it again in > start/stop streaming is a deadlock. Unless you think the locking should > be nested here, it seems to me that the mutex isn't needed. The V4L2 core can lock all ioctls using struct video_device::lock. For buffer- related ioctls, it can optionally use a separate lock from struct vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2- ioctl.c. The vpif-capture driver sets both the video_device and vb2_queue locks to the same lock (which would have the same effect as leaving the vb2_queue lock NULL). All ioctls are thus serialized. You would only need to handle locking in start_streaming and stop_streaming manually if you didn't rely on the core serializing the ioctls.
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes: > Hi Kevin, > > On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote: >> Laurent Pinchart writes: >> > On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote: >> >> Video capture subdevs may be over I2C and may sleep during xfer, so we >> >> cannot do IRQ-disabled locking when calling the subdev. >> >> >> >> Signed-off-by: Kevin Hilman <khilman@baylibre.com> >> >> --- >> >> drivers/media/platform/davinci/vpif_capture.c | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> >> b/drivers/media/platform/davinci/vpif_capture.c index >> >> 5104cc0ee40e..9f8f41c0f251 100644 >> >> --- a/drivers/media/platform/davinci/vpif_capture.c >> >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> >> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue >> >> *vq, unsigned int count) >> >> } >> >> } >> >> >> >> + spin_unlock_irqrestore(&common->irqlock, flags); >> >> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); >> >> + spin_lock_irqsave(&common->irqlock, flags); >> > >> > I always get anxious when I see a spinlock being released randomly with an >> > operation in the middle of a protected section. Looking at the code it >> > looks like the spinlock is abused here. irqlock should only protect the >> > dma_queue and should thus only be taken around the following code: >> > >> > spin_lock_irqsave(&common->irqlock, flags); >> > /* Get the next frame from the buffer queue */ >> > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next, >> > struct vpif_cap_buffer, list); >> > >> > /* Remove buffer from the buffer queue */ >> > list_del(&common->cur_frm->list); >> > spin_unlock_irqrestore(&common->irqlock, flags); >> >> Yes, that looks correct. Will update. >> >> > The code that is currently protected by the lock in the start and stop >> > streaming functions should be protected by a mutex instead. >> >> I tried taking the mutex here, but lockdep pointed out a deadlock. I >> may not be fully understanding the V4L2 internals here, but it seems >> that the ioctl is already taking a mutex, so taking it again in >> start/stop streaming is a deadlock. Unless you think the locking should >> be nested here, it seems to me that the mutex isn't needed. > > The V4L2 core can lock all ioctls using struct video_device::lock. For buffer- > related ioctls, it can optionally use a separate lock from struct > vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2- > ioctl.c. > > The vpif-capture driver sets both the video_device and vb2_queue locks to the > same lock (which would have the same effect as leaving the vb2_queue lock > NULL). All ioctls are thus serialized. You would only need to handle locking > in start_streaming and stop_streaming manually if you didn't rely on the core > serializing the ioctls. OK, thanks for clarifying how that works. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index 5104cc0ee40e..9f8f41c0f251 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count) } } + spin_unlock_irqrestore(&common->irqlock, flags); ret = v4l2_subdev_call(ch->sd, video, s_stream, 1); + spin_lock_irqsave(&common->irqlock, flags); + if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) { vpif_dbg(1, debug, "stream on failed in subdev\n"); goto err;