* [PATCH] media: ov5640: fix use of destroyed mutex
@ 2020-03-13 8:22 Tomi Valkeinen
2020-03-13 11:45 ` Laurent Pinchart
2020-03-13 13:19 ` [PATCH v2] " Tomi Valkeinen
0 siblings, 2 replies; 5+ messages in thread
From: Tomi Valkeinen @ 2020-03-13 8:22 UTC (permalink / raw)
To: Steve Longerbeam, Mauro Carvalho Chehab, linux-media, Benoit Parrot
Cc: Laurent Pinchart, Tomi Valkeinen, stable
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
in the use of the destroyed mutex.
Fix this by calling v4l2_ctrl_handler_free() before mutex_destroy().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: stable@vger.kernel.org
---
drivers/media/i2c/ov5640.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 854031f0b64a..64511de4eea8 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_client *client)
struct ov5640_dev *sensor = to_ov5640_dev(sd);
v4l2_async_unregister_subdev(&sensor->sd);
+ v4l2_ctrl_handler_free(&sensor->ctrls.handler);
mutex_destroy(&sensor->lock);
media_entity_cleanup(&sensor->sd.entity);
- v4l2_ctrl_handler_free(&sensor->ctrls.handler);
return 0;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] media: ov5640: fix use of destroyed mutex
2020-03-13 8:22 [PATCH] media: ov5640: fix use of destroyed mutex Tomi Valkeinen
@ 2020-03-13 11:45 ` Laurent Pinchart
2020-03-13 13:19 ` [PATCH v2] " Tomi Valkeinen
1 sibling, 0 replies; 5+ messages in thread
From: Laurent Pinchart @ 2020-03-13 11:45 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Steve Longerbeam, Mauro Carvalho Chehab, linux-media,
Benoit Parrot, stable
Hi Tomi,
Thank you for the patch.
On Fri, Mar 13, 2020 at 10:22:58AM +0200, Tomi Valkeinen wrote:
> v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
> to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
> sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
> in the use of the destroyed mutex.
>
> Fix this by calling v4l2_ctrl_handler_free() before mutex_destroy().
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/media/i2c/ov5640.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 854031f0b64a..64511de4eea8 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_client *client)
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
>
> v4l2_async_unregister_subdev(&sensor->sd);
> + v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> mutex_destroy(&sensor->lock);
> media_entity_cleanup(&sensor->sd.entity);
> - v4l2_ctrl_handler_free(&sensor->ctrls.handler);
While at it, could you move the mutex after media_entity_cleanup() too,
to avoid future problems in case it gets used through that path ?
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> return 0;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2] media: ov5640: fix use of destroyed mutex
2020-03-13 8:22 [PATCH] media: ov5640: fix use of destroyed mutex Tomi Valkeinen
2020-03-13 11:45 ` Laurent Pinchart
@ 2020-03-13 13:19 ` Tomi Valkeinen
2020-03-19 21:59 ` Benoit Parrot
2020-03-25 12:20 ` [PATCH v3] " Tomi Valkeinen
1 sibling, 2 replies; 5+ messages in thread
From: Tomi Valkeinen @ 2020-03-13 13:19 UTC (permalink / raw)
To: Steve Longerbeam, Mauro Carvalho Chehab, linux-media,
Benoit Parrot, Laurent Pinchart
Cc: Tomi Valkeinen, stable
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
in the use of the destroyed mutex.
Fix this by calling moving the mutex_destroy() to the end of the cleanup
sequence, as there's no need to destroy the mutex as early as possible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@vger.kernel.org
---
drivers/media/i2c/ov5640.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 854031f0b64a..2fe4a7ac0592 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -3093,8 +3093,8 @@ static int ov5640_probe(struct i2c_client *client)
free_ctrls:
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
entity_cleanup:
- mutex_destroy(&sensor->lock);
media_entity_cleanup(&sensor->sd.entity);
+ mutex_destroy(&sensor->lock);
return ret;
}
@@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_client *client)
struct ov5640_dev *sensor = to_ov5640_dev(sd);
v4l2_async_unregister_subdev(&sensor->sd);
- mutex_destroy(&sensor->lock);
media_entity_cleanup(&sensor->sd.entity);
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
+ mutex_destroy(&sensor->lock);
return 0;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2] media: ov5640: fix use of destroyed mutex
2020-03-13 13:19 ` [PATCH v2] " Tomi Valkeinen
@ 2020-03-19 21:59 ` Benoit Parrot
2020-03-25 12:20 ` [PATCH v3] " Tomi Valkeinen
1 sibling, 0 replies; 5+ messages in thread
From: Benoit Parrot @ 2020-03-19 21:59 UTC (permalink / raw)
To: Tomi Valkeinen, Steve Longerbeam, Mauro Carvalho Chehab,
linux-media, Laurent Pinchart
Cc: stable
Reviewed-by: Benoit Parrot <bparrot@ti.com>
On 3/13/20 8:19 AM, Tomi Valkeinen wrote:
> v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
> to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
> sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
> in the use of the destroyed mutex.
>
> Fix this by calling moving the mutex_destroy() to the end of the cleanup
> sequence, as there's no need to destroy the mutex as early as possible.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/media/i2c/ov5640.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 854031f0b64a..2fe4a7ac0592 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -3093,8 +3093,8 @@ static int ov5640_probe(struct i2c_client *client)
> free_ctrls:
> v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> entity_cleanup:
> - mutex_destroy(&sensor->lock);
> media_entity_cleanup(&sensor->sd.entity);
> + mutex_destroy(&sensor->lock);
> return ret;
> }
>
> @@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_client *client)
> struct ov5640_dev *sensor = to_ov5640_dev(sd);
>
> v4l2_async_unregister_subdev(&sensor->sd);
> - mutex_destroy(&sensor->lock);
> media_entity_cleanup(&sensor->sd.entity);
> v4l2_ctrl_handler_free(&sensor->ctrls.handler);
> + mutex_destroy(&sensor->lock);
>
> return 0;
> }
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v3] media: ov5640: fix use of destroyed mutex
2020-03-13 13:19 ` [PATCH v2] " Tomi Valkeinen
2020-03-19 21:59 ` Benoit Parrot
@ 2020-03-25 12:20 ` Tomi Valkeinen
1 sibling, 0 replies; 5+ messages in thread
From: Tomi Valkeinen @ 2020-03-25 12:20 UTC (permalink / raw)
To: linux-media, Steve Longerbeam, Mauro Carvalho Chehab,
Benoit Parrot, Laurent Pinchart
Cc: Tomi Valkeinen, stable
v4l2_ctrl_handler_free() uses hdl->lock, which in ov5640 driver is set
to sensor's own sensor->lock. In ov5640_remove(), the driver destroys the
sensor->lock first, and then calls v4l2_ctrl_handler_free(), resulting
in the use of the destroyed mutex.
Fix this by calling moving the mutex_destroy() to the end of the cleanup
sequence, as there's no need to destroy the mutex as early as possible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: stable@vger.kernel.org # v4.14+
Reviewed-by: Benoit Parrot <bparrot@ti.com>
---
Added reviewed-by from Benoit
Added stable version
drivers/media/i2c/ov5640.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 854031f0b64a..2fe4a7ac0592 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -3093,8 +3093,8 @@ static int ov5640_probe(struct i2c_client *client)
free_ctrls:
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
entity_cleanup:
- mutex_destroy(&sensor->lock);
media_entity_cleanup(&sensor->sd.entity);
+ mutex_destroy(&sensor->lock);
return ret;
}
@@ -3104,9 +3104,9 @@ static int ov5640_remove(struct i2c_client *client)
struct ov5640_dev *sensor = to_ov5640_dev(sd);
v4l2_async_unregister_subdev(&sensor->sd);
- mutex_destroy(&sensor->lock);
media_entity_cleanup(&sensor->sd.entity);
v4l2_ctrl_handler_free(&sensor->ctrls.handler);
+ mutex_destroy(&sensor->lock);
return 0;
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-03-25 12:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-13 8:22 [PATCH] media: ov5640: fix use of destroyed mutex Tomi Valkeinen
2020-03-13 11:45 ` Laurent Pinchart
2020-03-13 13:19 ` [PATCH v2] " Tomi Valkeinen
2020-03-19 21:59 ` Benoit Parrot
2020-03-25 12:20 ` [PATCH v3] " Tomi Valkeinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).