From: Max Kellermann <max@duempel.org>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-media@vger.kernel.org, shuahkh@osg.samsung.com,
mchehab@osg.samsung.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] drivers/media/media-entity: clear media_gobj.mdev in _destroy()
Date: Fri, 17 Jun 2016 15:04:03 +0200 [thread overview]
Message-ID: <20160617130403.GA9229@swift.blarg.de> (raw)
In-Reply-To: <20160617125317.GF24980@valkosipuli.retiisi.org.uk>
On 2016/06/17 14:53, Sakari Ailus <sakari.ailus@iki.fi> wrote:
> On Wed, Jun 15, 2016 at 10:15:07PM +0200, 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
>
> Is that something that should really happen, and why? The same object should
> not be unregistered more than once --- in many call paths gobj
> unregistration is followed by kfree() on the gobj.
True, it should not happen, and I think the code is currently
misdesigned (or I just don't grasp it correctly; I may be wrong).
The "gobj" is inserted into a linked list, the list's owner
(media_device) feels responsible to free items in that list. Plus,
the dvb_device instances holds a pointer and also tries to free it.
Usually, dvbdev.c destruction gets called first, which removes the
"gobj" from the linked list, and media_device never sees it during its
own destruction. But that ordering is all but guaranteed. It just
happens to be that way under "normal" circumstances.
None of this makes any sense to me. There appears to be lots of bogus
and unsafe code. I'm still waiting for somebody with more clue to
enlighten me.
Max
next prev parent reply other threads:[~2016-06-17 13:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 20:15 [PATCH 1/3] drivers/media/dvb-core/en50221: use kref to manage struct dvb_ca_private Max Kellermann
2016-06-15 20:15 ` [PATCH 2/3] drivers/media/media-entity: clear media_gobj.mdev in _destroy() Max Kellermann
2016-06-16 16:24 ` Shuah Khan
2016-06-16 18:43 ` Max Kellermann
2016-06-16 18:55 ` Shuah Khan
2016-06-17 12:53 ` Sakari Ailus
2016-06-17 13:04 ` Max Kellermann [this message]
2016-06-15 20:15 ` [PATCH 3/3] drivers/media/media-device: fix double free bug in _unregister() Max Kellermann
2016-06-15 20:32 ` Shuah Khan
2016-06-15 20:37 ` Max Kellermann
2016-06-15 21:50 ` Shuah Khan
2016-06-16 9:29 ` Max Kellermann
2016-06-16 13:40 ` Shuah Khan
2016-06-16 16:06 ` [PATCH 1/3] drivers/media/dvb-core/en50221: use kref to manage struct dvb_ca_private Shuah Khan
2016-06-16 18:37 ` Max Kellermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160617130403.GA9229@swift.blarg.de \
--to=max@duempel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=shuahkh@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox