[PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Ricardo Ribalda Delgado]

vb2_fop_relase does not held the lock although it is modifying the
queue->owner field.

This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:

[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0000000000000260
[ 308.297759] IP: [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: 0000 #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: ffff8801564e1690 ti: ffff88014dc02000 task.ti:
ffff88014dc02000
[ 308.297962] RIP: 0010:[<ffffffffa07a9fd2>] [<ffffffffa07a9fd2>]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:ffff88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: 0000000000000000 RBX: ffff880158a23000 RCX: dead000000100100
[ 308.298003] RDX: 0000000000000000 RSI: dead000000200200 RDI: 0000000000000000
[ 308.298012] RBP: ffff88014dc03e58 R08: 0000000000000000 R09: 0000000000000001
[ 308.298020] R10: ffffea00051e8380 R11: ffff88014dc03fd8 R12: ffff880158a23070
[ 308.298029] R13: ffff8801549040b8 R14: 0000000000198000 R15: 0000000001887e60
[ 308.298040] FS: 00007f65130d5700(0000) GS:ffff88015ed00000(0000)
knlGS:0000000000000000
[ 308.298049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 308.298057] CR2: 0000000000000260 CR3: 0000000159630000 CR4: 00000000000007e0
[ 308.298064] Stack:
[ 308.298071] ffff880156416c00 0000000000198000 0000000000000000
ffff880100000001
[ 308.298087] ffff88014dc03f50 00000000810a79ca 0002000000000001
ffff880154904718
[ 308.298101] ffff880156416c00 0000000000198000 ffff880154904338
ffff88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [<ffffffffa07aa3c4>] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [<ffffffffa07aa494>] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [<ffffffff8154ee9e>] v4l2_read+0x7e/0xc0
[ 308.298296] [<ffffffff8116e639>] vfs_read+0xa9/0x160
[ 308.298312] [<ffffffff8116e882>] SyS_read+0x52/0xb0
[ 308.298328] [<ffffffff81784179>] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP <ffff88014dc03df8>
[ 308.298514] CR2: 0000000000000260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 drivers/media/v4l2-core/videobuf2-core.c | 7 +++++++
 1 file changed, 7 insertions(+)

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);
 }
-- 
1.8.4.rc3

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Hans Verkuil]

On 10/14/13 09:41, Ricardo Ribalda Delgado wrote:
> vb2_fop_relase does not held the lock although it is modifying the
> queue->owner field.
> 
> This could lead to race conditions on the vb2_perform_io function
> when multiple applications are accessing the video device via
> read/write API:
> 
> [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000260
> [ 308.297759] IP: [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
> [videobuf2_core]
> [ 308.297794] PGD 159719067 PUD 158119067 PMD 0
> [ 308.297812] Oops: 0000 #1 SMP
> [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
> qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
> qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
> spi_xilinx spi_bitbang qt5023
> [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
> [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
> PM_2.1.0.309 X64 05/23/2013
> [ 308.297952] task: ffff8801564e1690 ti: ffff88014dc02000 task.ti:
> ffff88014dc02000
> [ 308.297962] RIP: 0010:[<ffffffffa07a9fd2>] [<ffffffffa07a9fd2>]
> vb2_perform_fileio+0x372/0x610 [videobuf2_core]
> [ 308.297985] RSP: 0018:ffff88014dc03df8 EFLAGS: 00010202
> [ 308.297995] RAX: 0000000000000000 RBX: ffff880158a23000 RCX: dead000000100100
> [ 308.298003] RDX: 0000000000000000 RSI: dead000000200200 RDI: 0000000000000000
> [ 308.298012] RBP: ffff88014dc03e58 R08: 0000000000000000 R09: 0000000000000001
> [ 308.298020] R10: ffffea00051e8380 R11: ffff88014dc03fd8 R12: ffff880158a23070
> [ 308.298029] R13: ffff8801549040b8 R14: 0000000000198000 R15: 0000000001887e60
> [ 308.298040] FS: 00007f65130d5700(0000) GS:ffff88015ed00000(0000)
> knlGS:0000000000000000
> [ 308.298049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 308.298057] CR2: 0000000000000260 CR3: 0000000159630000 CR4: 00000000000007e0
> [ 308.298064] Stack:
> [ 308.298071] ffff880156416c00 0000000000198000 0000000000000000
> ffff880100000001
> [ 308.298087] ffff88014dc03f50 00000000810a79ca 0002000000000001
> ffff880154904718
> [ 308.298101] ffff880156416c00 0000000000198000 ffff880154904338
> ffff88014dc03f50
> [ 308.298116] Call Trace:
> [ 308.298143] [<ffffffffa07aa3c4>] vb2_read+0x14/0x20 [videobuf2_core]
> [ 308.298198] [<ffffffffa07aa494>] vb2_fop_read+0xc4/0x120 [videobuf2_core]
> [ 308.298252] [<ffffffff8154ee9e>] v4l2_read+0x7e/0xc0
> [ 308.298296] [<ffffffff8116e639>] vfs_read+0xa9/0x160
> [ 308.298312] [<ffffffff8116e882>] SyS_read+0x52/0xb0
> [ 308.298328] [<ffffffff81784179>] tracesys+0xd0/0xd5
> [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
> 44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
> 44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
> 89
> [ 308.298487] RIP [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
> [videobuf2_core]
> [ 308.298507] RSP <ffff88014dc03df8>
> [ 308.298514] CR2: 0000000000000260
> [ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
> 
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>

Thanks!

	Hans

> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> 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);
>  }
> 

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Marek Szyprowski]

Hello,

On 2013-10-14 09:41, Ricardo Ribalda Delgado wrote:
> vb2_fop_relase does not held the lock although it is modifying the
> queue->owner field.
>
> This could lead to race conditions on the vb2_perform_io function
> when multiple applications are accessing the video device via
> read/write API:
>
> [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000260
> [ 308.297759] IP: [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
> [videobuf2_core]
> [ 308.297794] PGD 159719067 PUD 158119067 PMD 0
> [ 308.297812] Oops: 0000 #1 SMP
> [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
> qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
> qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
> spi_xilinx spi_bitbang qt5023
> [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
> [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
> PM_2.1.0.309 X64 05/23/2013
> [ 308.297952] task: ffff8801564e1690 ti: ffff88014dc02000 task.ti:
> ffff88014dc02000
> [ 308.297962] RIP: 0010:[<ffffffffa07a9fd2>] [<ffffffffa07a9fd2>]
> vb2_perform_fileio+0x372/0x610 [videobuf2_core]
> [ 308.297985] RSP: 0018:ffff88014dc03df8 EFLAGS: 00010202
> [ 308.297995] RAX: 0000000000000000 RBX: ffff880158a23000 RCX: dead000000100100
> [ 308.298003] RDX: 0000000000000000 RSI: dead000000200200 RDI: 0000000000000000
> [ 308.298012] RBP: ffff88014dc03e58 R08: 0000000000000000 R09: 0000000000000001
> [ 308.298020] R10: ffffea00051e8380 R11: ffff88014dc03fd8 R12: ffff880158a23070
> [ 308.298029] R13: ffff8801549040b8 R14: 0000000000198000 R15: 0000000001887e60
> [ 308.298040] FS: 00007f65130d5700(0000) GS:ffff88015ed00000(0000)
> knlGS:0000000000000000
> [ 308.298049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 308.298057] CR2: 0000000000000260 CR3: 0000000159630000 CR4: 00000000000007e0
> [ 308.298064] Stack:
> [ 308.298071] ffff880156416c00 0000000000198000 0000000000000000
> ffff880100000001
> [ 308.298087] ffff88014dc03f50 00000000810a79ca 0002000000000001
> ffff880154904718
> [ 308.298101] ffff880156416c00 0000000000198000 ffff880154904338
> ffff88014dc03f50
> [ 308.298116] Call Trace:
> [ 308.298143] [<ffffffffa07aa3c4>] vb2_read+0x14/0x20 [videobuf2_core]
> [ 308.298198] [<ffffffffa07aa494>] vb2_fop_read+0xc4/0x120 [videobuf2_core]
> [ 308.298252] [<ffffffff8154ee9e>] v4l2_read+0x7e/0xc0
> [ 308.298296] [<ffffffff8116e639>] vfs_read+0xa9/0x160
> [ 308.298312] [<ffffffff8116e882>] SyS_read+0x52/0xb0
> [ 308.298328] [<ffffffff81784179>] tracesys+0xd0/0xd5
> [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
> 44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
> 44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
> 89
> [ 308.298487] RIP [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
> [videobuf2_core]
> [ 308.298507] RSP <ffff88014dc03df8>
> [ 308.298514] CR2: 0000000000000260
> [ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>

Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>

> ---
>   drivers/media/v4l2-core/videobuf2-core.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> 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);
>   }

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Sylwester Nawrocki]

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 <s.nawrocki@samsung.com>
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 <s.nawrocki@samsung.com>
---
  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);

-- 
1.7.4.1

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Ricardo Ribalda Delgado]

Hello Sylwester

On Sat, Oct 19, 2013 at 11:55 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> 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);
>
Very good catch, thanks!

> 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.

IMHO this will lead to the same type of mistakes in the future.

 What about creating a function __vb2_fop_release that does exactly
the same as the original function but with an extra parameter bool
lock_held

vb2_fop_release will be a wrapper for that funtion with lock_held== false

drivers that overload the fop_release and need to hold the lock will
call the __ function with lock_held= true

What do you think?

Thanks!

>
>
> From 3617684d759bb021e3cf1d862a91cb6e18d12052 Mon Sep 17 00:00:00 2001
> From: Sylwester Nawrocki <s.nawrocki@samsung.com>
> 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 <s.nawrocki@samsung.com>
> ---
>  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);
>
> --
> 1.7.4.1



-- 
Ricardo Ribalda

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Sylwester Nawrocki]

On 10/19/2013 12:22 PM, Ricardo Ribalda Delgado wrote:
> On Sat, Oct 19, 2013 at 11:55 AM, Sylwester Nawrocki
> <sylvester.nawrocki@gmail.com>  wrote:
>> >  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);
>> >
>
> Very good catch, thanks!
>
>> >  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.
>
> IMHO this will lead to the same type of mistakes in the future.
>
>   What about creating a function __vb2_fop_release that does exactly
> the same as the original function but with an extra parameter bool
> lock_held
>
> vb2_fop_release will be a wrapper for that funtion with lock_held== false

Hmm, the parameter would be telling whether the lock is already held ? 
Perhaps
we should inverse its meaning and it should indicate whether 
vb2_fop_release()
should be taking the lock internally ? It seems to me more straightforward.

> drivers that overload the fop_release and need to hold the lock will
> call the __ function with lock_held= true
>
> What do you think?

I was also considering this, it's probably better. I'm not sure about 
exporting
functions prefixed with __ though. And the locking becomes less clear 
with such
functions proliferation.

Anyway, I'm in general personally OK with having an additional version like:

__vb2_fop_release(struct file *filp, bool lock);


Regards,
Sylwester

Re: [PATCH] videobuf2: Add missing lock held on vb2_fop_relase

[Ricardo Ribalda Delgado]

Hello Sylwester

I have just posted a new version. Please take a look to it, it should
fix your issue.

I havent tried it in hw because I am out of the office.

Regards!

On Sat, Oct 19, 2013 at 12:51 PM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> On 10/19/2013 12:22 PM, Ricardo Ribalda Delgado wrote:
>>
>> On Sat, Oct 19, 2013 at 11:55 AM, Sylwester Nawrocki
>> <sylvester.nawrocki@gmail.com>  wrote:
>>>
>>> >  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);
>>> >
>>
>>
>> Very good catch, thanks!
>>
>>> >  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.
>>
>>
>> IMHO this will lead to the same type of mistakes in the future.
>>
>>   What about creating a function __vb2_fop_release that does exactly
>> the same as the original function but with an extra parameter bool
>> lock_held
>>
>> vb2_fop_release will be a wrapper for that funtion with lock_held== false
>
>
> Hmm, the parameter would be telling whether the lock is already held ?
> Perhaps
> we should inverse its meaning and it should indicate whether
> vb2_fop_release()
> should be taking the lock internally ? It seems to me more straightforward.
>
>
>> drivers that overload the fop_release and need to hold the lock will
>> call the __ function with lock_held= true
>>
>> What do you think?
>
>
> I was also considering this, it's probably better. I'm not sure about
> exporting
> functions prefixed with __ though. And the locking becomes less clear with
> such
> functions proliferation.
>
> Anyway, I'm in general personally OK with having an additional version like:
>
> __vb2_fop_release(struct file *filp, bool lock);
>
>
> Regards,
> Sylwester



-- 
Ricardo Ribalda