[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5762D2A0.605@osg.samsung.com>
Date: Thu, 16 Jun 2016 10:24:00 -0600
From: Shuah Khan <shuahkh@....samsung.com>
To: Max Kellermann <max@...mpel.org>, linux-media@...r.kernel.org,
mchehab@....samsung.com
Cc: linux-kernel@...r.kernel.org, Shuah Khan <shuahkh@....samsung.com>
Subject: Re: [PATCH 2/3] drivers/media/media-entity: clear media_gobj.mdev in
_destroy()
On 06/15/2016 02:15 PM, Max Kellermann wrote:
> media_gobj_destroy() may be called twice on one instance - once by
> media_device_unregister() and again by dvb_media_device_free(). The
> function media_remove_intf_links() establishes and documents the
> convention that mdev==NULL means that the object is not registered,
> but nobody ever NULLs this variable. So this patch really implements
> this behavior, and adds another mdev==NULL check to
> media_gobj_destroy() to protect against double removal.
Are you seeing null pointer dereference on gobj->mdev? In any case,
we have to look at if there is a missing mutex hold that creates a
race between media_device_unregister() and dvb_media_device_free()
I don't this patch will solve the race condition.
thanks,
-- Shuah
>
> Signed-off-by: Max Kellermann <max@...mpel.org>
> ---
> drivers/media/media-entity.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index d8a2299..9526338 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -203,10 +203,16 @@ void media_gobj_destroy(struct media_gobj *gobj)
> {
> dev_dbg_obj(__func__, gobj);
>
> + /* Do nothing if the object is not linked. */
> + if (gobj->mdev == NULL)
> + return;
> +
> gobj->mdev->topology_version++;
>
> /* Remove the object from mdev list */
> list_del(&gobj->list);
> +
> + gobj->mdev = NULL;
> }
>
> int media_entity_pads_init(struct media_entity *entity, u16 num_pads,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists