From patchwork Sat Oct 19 09:55:01 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sylwester Nawrocki X-Patchwork-Id: 3071671 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 49D7B9F288 for ; Sat, 19 Oct 2013 09:55:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 51E9820502 for ; Sat, 19 Oct 2013 09:55:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 280FC20489 for ; Sat, 19 Oct 2013 09:55:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751084Ab3JSJze (ORCPT ); Sat, 19 Oct 2013 05:55:34 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:39236 "EHLO mail-wi0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750843Ab3JSJzG (ORCPT ); Sat, 19 Oct 2013 05:55:06 -0400 Received: by mail-wi0-f171.google.com with SMTP id h11so2021879wiv.10 for ; Sat, 19 Oct 2013 02:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dosy+hyjKNGvfRdj9wrusrQfOR8oBTnUe6ng22wHcnY=; b=mQPqh+sC+KRjLD+gEHPYQDdopZmk4ShwTdqR0iG9if0HVgfx6aC4ZtAc3lTAQlroqA CedOrvEiWN6wmi47TMAsEvZimpaH0rRKMJiKmIO2dx7YA9DoCqEFMlIetgXHIVHqAohx E7UpgoKVAgm++MDbBPKTXs5hEBsh2kMN7DJ1wAHggYe8RW1Ua/8zEEiSOjInrIr6y1JT cJMVPkHwYFG3MGVG0E5yCXalqssX1y7vmQ+ovGviuJxZ3Y8/Ul8fWR/HpV89EPIukRQx DOdDfOB2BTp1rHMN4yY8I4IpZhWyQEnlrNGruRWcGm2szJN38ZOXoPpPvTOPXNfQ5Vbs 6cEg== X-Received: by 10.180.89.225 with SMTP id br1mr2670732wib.50.1382176505259; Sat, 19 Oct 2013 02:55:05 -0700 (PDT) Received: from [192.168.1.110] (093105185086.warszawa.vectranet.pl. [93.105.185.86]) by mx.google.com with ESMTPSA id ev4sm35137192wib.7.2013.10.19.02.55.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 02:55:04 -0700 (PDT) Message-ID: <526256F5.1060404@gmail.com> Date: Sat, 19 Oct 2013 11:55:01 +0200 From: Sylwester Nawrocki User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ricardo Ribalda Delgado CC: Pawel Osciak , Marek Szyprowski , Kyungmin Park , Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Hans Verkuil Subject: Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase References: <1381736489-27852-1-git-send-email-ricardo.ribalda@gmail.com> In-Reply-To: <1381736489-27852-1-git-send-email-ricardo.ribalda@gmail.com> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Ricardo, On 10/14/2013 09:41 AM, Ricardo Ribalda Delgado wrote: > vb2_fop_relase does not held the lock although it is modifying the > queue->owner field. [...] > diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c > index 9fc4bab..3a961ee 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -2588,8 +2588,15 @@ int vb2_fop_release(struct file *file) > struct video_device *vdev = video_devdata(file); > > if (file->private_data == vdev->queue->owner) { > + struct mutex *lock; > + > + lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; > + if (lock) > + mutex_lock(lock); > vb2_queue_release(vdev->queue); > vdev->queue->owner = NULL; > + if (lock) > + mutex_unlock(lock); > } > return v4l2_fh_release(file); > } It seems you didn't inspect all users of vb2_fop_release(). There are 3 drivers that don't assign vb2_fop_release() to struct v4l2_file_operations directly but instead call it from within its own release() handler. Two of them do call vb2_fop_release() with the video queue lock already held. $ git grep -n vb2_fop_rel -- drivers/media/ drivers/media/platform/exynos4-is/fimc-capture.c:552: ret = vb2_fop_release(file); drivers/media/platform/exynos4-is/fimc-lite.c:549: vb2_fop_release(file); A rather ugly solution would be to open code the vb2_fop_release() function in those driver, like in below patch (untested). Unless there are better proposals I would queue the patch as below together with the $subject patch upstream. From 3617684d759bb021e3cf1d862a91cb6e18d12052 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Sat, 19 Oct 2013 11:48:10 +0200 Subject: [PATCH] exynos4-is: Do not call vb2_fop_release() with queue lock held Currently vb2_fop_release() function doesn't take the queue lock, but it is going to change and then there would happen a deadlock in fimc_capture_release() and fimc_lite_release(), since these function take the video queue lock prior to calling vb2_fop_release(). To avoid a deadlock open code the vb2_fop_release() function in those drivers. Signed-off-by: Sylwester Nawrocki --- drivers/media/platform/exynos4-is/fimc-capture.c | 11 ++++++++--- drivers/media/platform/exynos4-is/fimc-lite.c | 8 +++++++- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c b/drivers/media/platform/exynos4-is/fimc-capture.c index fb27ff7..e9a5c90 100644 --- a/drivers/media/platform/exynos4-is/fimc-capture.c +++ b/drivers/media/platform/exynos4-is/fimc-capture.c @@ -537,6 +537,7 @@ static int fimc_capture_release(struct file *file) { struct fimc_dev *fimc = video_drvdata(file); struct fimc_vid_cap *vc = &fimc->vid_cap; + struct video_device *vdev = &vc->ve.vdev; bool close = v4l2_fh_is_singular_file(file); int ret; @@ -545,11 +546,15 @@ static int fimc_capture_release(struct file *file) mutex_lock(&fimc->lock); if (close && vc->streaming) { - media_entity_pipeline_stop(&vc->ve.vdev.entity); + media_entity_pipeline_stop(&vdev->entity); vc->streaming = false; } - ret = vb2_fop_release(file); + if (file->private_data == vdev->queue->owner) { + vb2_queue_release(vdev->queue); + vdev->queue->owner = NULL; + } + ret = v4l2_fh_release(file); if (close) { clear_bit(ST_CAPT_BUSY, &fimc->state); @@ -557,7 +562,7 @@ static int fimc_capture_release(struct file *file) clear_bit(ST_CAPT_SUSPENDED, &fimc->state); fimc_md_graph_lock(&vc->ve); - vc->ve.vdev.entity.use_count--; + vdev->entity.use_count--; fimc_md_graph_unlock(&vc->ve); } diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c index e5798f7..182db3c 100644 --- a/drivers/media/platform/exynos4-is/fimc-lite.c +++ b/drivers/media/platform/exynos4-is/fimc-lite.c @@ -528,6 +528,7 @@ static int fimc_lite_release(struct file *file) { struct fimc_lite *fimc = video_drvdata(file); struct media_entity *entity = &fimc->ve.vdev.entity; + struct video_device *vdev = &fimc->ve.vdev; mutex_lock(&fimc->lock); @@ -546,7 +547,12 @@ static int fimc_lite_release(struct file *file) mutex_unlock(&entity->parent->graph_mutex); } - vb2_fop_release(file); + if (file->private_data == vdev->queue->owner) { + vb2_queue_release(vdev->queue); + vdev->queue->owner = NULL; + } + v4l2_fh_release(file); + pm_runtime_put(&fimc->pdev->dev); clear_bit(ST_FLITE_SUSPENDED, &fimc->state);