Re: [ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

Hi Mauro,

On Mon, Jan 30, 2017 at 09:56:46AM -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 30 Jan 2017 09:39:21 +0100
> Hans Verkuil  escreveu:
> 
> > On 28/01/17 16:35, Laurent Pinchart wrote:
> > > Hi Sakari,
> > >
> > > On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:  
> > >> On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:  
> > >>> Hi Sakari/Hans/Laurent,
> > >>>
> > >>> First of all, thanks for looking into those issues. Unfortunately, I was
> > >>> in vacations, and were not able to be with you there for such 
> > >>> discussions.
> > >>>
> > >>> While I have a somewhat different view on some of the introductory 
> > >>> points
> > >>> of this RFC, what really matters is the "proposal" part of it. So, based
> > >>> on the experiments I did when I addressed the hotplug issues with the
> > >>> media controller on USB drivers, I'm adding a few comments below.
> > >>>
> > >>> Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:  
> >  Allocating struct media_devnode separately from struct media_device
> >  ---
> > 
> >  The current codebase allocates struct media_devnode dynamically. This
> >  was done in order to reduce the time window during which unallocated
> >  kernel memory could be accessed. However, there is no specific need for
> >  such a separation as the entire data structure, including the media
> >  device which used to contain struct media_devnode, will have the same
> >  lifetime. Thus the struct media_devnode should be allocated as part of
> >  struct media_device. Later on, struct media_devnode may be merged with
> >  struct media_device if so decided.  
> > >>>
> > >>> There is one issue merging struct media_devnode at struct media_device.
> > >>> The problem is that, if the same struct device is used for two different
> > >>> APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> > >>> to the same struct device, you may end by having a double free when the
> > >>> device is unregistered on the second core. That's basically why
> > >>> currently struct cdev is at struct media_devnode: this way, it has its 
> > >>> own
> > >>> struct device.  
> > >>
> > >> One of the conclusions of the memorandum I wrote is that the data 
> > >> structures
> > >> that are involved in executing a system call (including IOCTLs) must stay
> > >> intact during that system call. (Well, the alternative I can think of is
> > >> using an rw_semaphore but I certainly do not advocate that solution.)
> > >>
> > >> Otherwise, we will continue to have serialisation issues: kernel memory 
> > >> that
> > >> may be released at any point of time independently of a system call in
> > >> progress:
> > >>
> > >>  > >>   
> > >>>  
> > >>
> > >> That one is a NULL pointer dereference but released kernel memory can be
> > >> accessed as well.
> > >>  
> 
> There's an alternative approach: to have a flag to indicate that the
> device got disconnected and denying access to the device-specific data
> if the device was already hot-unplugged. The V4L USB drivers do that
> already. See, for example, the em28xx driver:
> 
> int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16 reg,
>   char *buf, int len)
> {
> ...
>   if (dev->disconnected)
>   return -ENODEV;
> ...
> }
> 
> /* Processes and copies the URB data content (video and VBI data) */
> static inline int em28xx_urb_data_copy(struct em28xx *dev, struct urb *urb)
> {
> ...
>   if (dev->disconnected)
>   return 0;
> 
> The same logic exists on multiple places along the driver. Some of
> such checks could be moved to the core, but, if I remember well when
> such code was written, several such checks should be inside the driver,
> as the USB core doesn't allow any calls to their functions after the
> disconnect callback is called. That's why it was opted to not move
> it to the core.
> 
> In the case of DVB, the core has a similar logic to handle disconnected
> devices, with prevents it to call driver-specific code when a device is
> removed. That's why there are just 2 checks if dev->disconnected at
> drivers/media/usb/em28xx/em28xx-dvb.c: one at the IRQ logic, and the
> second one to avoid a race issue with the suspend code.
> 
> Due to that, on real hot-plug devices (USB drivers) that don't have
> hot-unplug issues with the V4L2 API, it should be safe to free some of
> their data structs at the .disconnect callback. Of course, the struct
> that embeds the struct device used as the cdev's parent can't be freed
> there.

I agree there's a need to prevent devices from accessing the hardware ---
please also see "Stopping the hardware safely at device unbind" below ---
but that's unrelated to accessing the media device or the media graph from
the user space and 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Mauro Carvalho Chehab]

Em Mon, 30 Jan 2017 09:39:21 +0100
Hans Verkuil  escreveu:

> On 28/01/17 16:35, Laurent Pinchart wrote:
> > Hi Sakari,
> >
> > On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:  
> >> On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:  
> >>> Hi Sakari/Hans/Laurent,
> >>>
> >>> First of all, thanks for looking into those issues. Unfortunately, I was
> >>> in vacations, and were not able to be with you there for such discussions.
> >>>
> >>> While I have a somewhat different view on some of the introductory points
> >>> of this RFC, what really matters is the "proposal" part of it. So, based
> >>> on the experiments I did when I addressed the hotplug issues with the
> >>> media controller on USB drivers, I'm adding a few comments below.
> >>>
> >>> Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:  
>  Allocating struct media_devnode separately from struct media_device
>  ---
> 
>  The current codebase allocates struct media_devnode dynamically. This
>  was done in order to reduce the time window during which unallocated
>  kernel memory could be accessed. However, there is no specific need for
>  such a separation as the entire data structure, including the media
>  device which used to contain struct media_devnode, will have the same
>  lifetime. Thus the struct media_devnode should be allocated as part of
>  struct media_device. Later on, struct media_devnode may be merged with
>  struct media_device if so decided.  
> >>>
> >>> There is one issue merging struct media_devnode at struct media_device.
> >>> The problem is that, if the same struct device is used for two different
> >>> APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> >>> to the same struct device, you may end by having a double free when the
> >>> device is unregistered on the second core. That's basically why
> >>> currently struct cdev is at struct media_devnode: this way, it has its own
> >>> struct device.  
> >>
> >> One of the conclusions of the memorandum I wrote is that the data 
> >> structures
> >> that are involved in executing a system call (including IOCTLs) must stay
> >> intact during that system call. (Well, the alternative I can think of is
> >> using an rw_semaphore but I certainly do not advocate that solution.)
> >>
> >> Otherwise, we will continue to have serialisation issues: kernel memory 
> >> that
> >> may be released at any point of time independently of a system call in
> >> progress:
> >>
> >>  >>   
> >>>  
> >>
> >> That one is a NULL pointer dereference but released kernel memory can be
> >> accessed as well.
> >>  

There's an alternative approach: to have a flag to indicate that the
device got disconnected and denying access to the device-specific data
if the device was already hot-unplugged. The V4L USB drivers do that
already. See, for example, the em28xx driver:

int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16 reg,
char *buf, int len)
{
...
if (dev->disconnected)
return -ENODEV;
...
}

/* Processes and copies the URB data content (video and VBI data) */
static inline int em28xx_urb_data_copy(struct em28xx *dev, struct urb *urb)
{
...
if (dev->disconnected)
return 0;

The same logic exists on multiple places along the driver. Some of
such checks could be moved to the core, but, if I remember well when
such code was written, several such checks should be inside the driver,
as the USB core doesn't allow any calls to their functions after the
disconnect callback is called. That's why it was opted to not move
it to the core.

In the case of DVB, the core has a similar logic to handle disconnected
devices, with prevents it to call driver-specific code when a device is
removed. That's why there are just 2 checks if dev->disconnected at
drivers/media/usb/em28xx/em28xx-dvb.c: one at the IRQ logic, and the
second one to avoid a race issue with the suspend code.

Due to that, on real hot-plug devices (USB drivers) that don't have
hot-unplug issues with the V4L2 API, it should be safe to free some of
their data structs at the .disconnect callback. Of course, the struct
that embeds the struct device used as the cdev's parent can't be freed
there.

> >>> IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
> >>> detected some race issues at the V4L2 side when I ran the bind/unbind
> >>> race tests, when we tried to merge the snd-usb-audio MC support patch.
> >>> I remember Shuah reported something similar on that time.
> >>>  
>  Allocating struct media_device dynamically
>  --
> 
>  Traditionally the media device has been allocated as part of drivers'
>  own structures. This is certainly fine as 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Hans Verkuil]

On 28/01/17 16:35, Laurent Pinchart wrote:

Hi Sakari,

On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:

On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:

Hi Sakari/Hans/Laurent,

First of all, thanks for looking into those issues. Unfortunately, I was
in vacations, and were not able to be with you there for such discussions.

While I have a somewhat different view on some of the introductory points
of this RFC, what really matters is the "proposal" part of it. So, based
on the experiments I did when I addressed the hotplug issues with the
media controller on USB drivers, I'm adding a few comments below.

Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:

Allocating struct media_devnode separately from struct media_device
---

The current codebase allocates struct media_devnode dynamically. This
was done in order to reduce the time window during which unallocated
kernel memory could be accessed. However, there is no specific need for
such a separation as the entire data structure, including the media
device which used to contain struct media_devnode, will have the same
lifetime. Thus the struct media_devnode should be allocated as part of
struct media_device. Later on, struct media_devnode may be merged with
struct media_device if so decided.


There is one issue merging struct media_devnode at struct media_device.
The problem is that, if the same struct device is used for two different
APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
to the same struct device, you may end by having a double free when the
device is unregistered on the second core. That's basically why
currently struct cdev is at struct media_devnode: this way, it has its own
struct device.


One of the conclusions of the memorandum I wrote is that the data structures
that are involved in executing a system call (including IOCTLs) must stay
intact during that system call. (Well, the alternative I can think of is
using an rw_semaphore but I certainly do not advocate that solution.)

Otherwise, we will continue to have serialisation issues: kernel memory that
may be released at any point of time independently of a system call in
progress:

Re: [ANN] Media object lifetime management meeting report from Oslo

[Laurent Pinchart]

Hi Sakari,

On Saturday 28 Jan 2017 00:02:53 Sakari Ailus wrote:
> On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:
> > Hi Sakari/Hans/Laurent,
> > 
> > First of all, thanks for looking into those issues. Unfortunately, I was
> > in vacations, and were not able to be with you there for such discussions.
> > 
> > While I have a somewhat different view on some of the introductory points
> > of this RFC, what really matters is the "proposal" part of it. So, based
> > on the experiments I did when I addressed the hotplug issues with the
> > media controller on USB drivers, I'm adding a few comments below.
> > 
> > Em Fri, 27 Jan 2017 12:08:22 +0200 Sakari Ailus escreveu:
> >> Allocating struct media_devnode separately from struct media_device
> >> ---
> >> 
> >> The current codebase allocates struct media_devnode dynamically. This
> >> was done in order to reduce the time window during which unallocated
> >> kernel memory could be accessed. However, there is no specific need for
> >> such a separation as the entire data structure, including the media
> >> device which used to contain struct media_devnode, will have the same
> >> lifetime. Thus the struct media_devnode should be allocated as part of
> >> struct media_device. Later on, struct media_devnode may be merged with
> >> struct media_device if so decided.
> > 
> > There is one issue merging struct media_devnode at struct media_device.
> > The problem is that, if the same struct device is used for two different
> > APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> > to the same struct device, you may end by having a double free when the
> > device is unregistered on the second core. That's basically why
> > currently struct cdev is at struct media_devnode: this way, it has its own
> > struct device.
> 
> One of the conclusions of the memorandum I wrote is that the data structures
> that are involved in executing a system call (including IOCTLs) must stay
> intact during that system call. (Well, the alternative I can think of is
> using an rw_semaphore but I certainly do not advocate that solution.)
> 
> Otherwise, we will continue to have serialisation issues: kernel memory that
> may be released at any point of time independently of a system call in
> progress:
> 
>  >
> 
> That one is a NULL pointer dereference but released kernel memory can be
> accessed as well.
> 
> > IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
> > detected some race issues at the V4L2 side when I ran the bind/unbind
> > race tests, when we tried to merge the snd-usb-audio MC support patch.
> > I remember Shuah reported something similar on that time.
> > 
> >> Allocating struct media_device dynamically
> >> --
> >> 
> >> Traditionally the media device has been allocated as part of drivers'
> >> own structures. This is certainly fine as such, but many drivers have
> >> allocated the driver private struct using the devm_() family of
> >> functions. This causes such memory to be released at the time of device
> >> removal rather than at the time when the memory is no longer accessible
> >> by e.g. user space processes or interrupt handlers. Besides the media
> >> device, the driver's own data structure is very likely to have the
> >> precisely same lifetime issue: it may also be accessed through IOCTLs
> >> after the device has been removed from the system.
> >> 
> >> Instead, the memory needs to be released as part of the release()
> >> callback of the media device which is called when the last reference to
> >> the media device is gone. Still, allocating the media device outside
> >> another containing driver specific struct will be required in some cases:
> >> sharing the media device mandates that. Implementing this can certainly
> >> be postponed until sharing the media device is otherwise supported as
> >> well.
> > 
> > The patches adding MC support for snd-usb-audio, pending since Kernel
> > 4.7 (I guess) require such functionatilty. Last year, on the audio
> > summit, they asked about its status, as they're needing MC suppor there.
> > 
> > So, whatever solution taken, this should be part of the solution.
> > 
> > (c/c Shuah, as she is the one working on it)
> 
> I think we should postpone that, or at least resolve that in a separate
> patchset. This is already getting very big. The refcounting problems will be
> harder to fix, should we extend the MC framework with media device sharing
> without considering the object lifetime issues first. So the order should
> be: first fix object lifetime issues, then add more features.

I strongly second that, continuing to build on top of a totally broken base 
can only lead to disaster. Given that we have given the lifetime management 
problem lots of thoughts already, with a patch 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

Hi Mauro,

Obrigado for the comments! Please see my replies below.

On Fri, Jan 27, 2017 at 09:38:31AM -0200, Mauro Carvalho Chehab wrote:
> Hi Sakari/Hans/Laurent,
> 
> First of all, thanks for looking into those issues. Unfortunately, I was in
> vacations, and were not able to be with you there for such discussions.
> 
> While I have a somewhat different view on some of the introductory points of 
> this RFC, what really matters is the "proposal" part of it. So, based on the
> experiments I did when I addressed the hotplug issues with the media
> controller on USB drivers, I'm adding a few comments below.
> 
> 
> Em Fri, 27 Jan 2017 12:08:22 +0200
> Sakari Ailus  escreveu:
> 
> > Allocating struct media_devnode separately from struct media_device
> > ---
> > 
> > The current codebase allocates struct media_devnode dynamically. This was
> > done in order to reduce the time window during which unallocated kernel
> > memory could be accessed. However, there is no specific need for such a
> > separation as the entire data structure, including the media device which
> > used to contain struct media_devnode, will have the same lifetime. Thus the
> > struct media_devnode should be allocated as part of struct media_device.
> > Later on, struct media_devnode may be merged with struct media_device if so
> > decided.
> 
> There is one issue merging struct media_devnode at struct media_device.
> The problem is that, if the same struct device is used for two different
> APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
> to the same struct device, you may end by having a double free when the
> device is unregistered on the second core. That's basically why 
> currently struct cdev is at struct media_devnode: this way, it has its own
> struct device.

One of the conclusions of the memorandum I wrote is that the data structures
that are involved in executing a system call (including IOCTLs) must stay
intact during that system call. (Well, the alternative I can think of is
using an rw_semaphore but I certainly do not advocate that solution.)

Otherwise, we will continue to have serialisation issues: kernel memory that
may be released at any point of time independently of a system call in
progress:



That one is a NULL pointer dereference but released kernel memory can be
accessed as well.

> 
> IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
> detected some race issues at the V4L2 side when I ran the bind/unbind
> race tests, when we tried to merge the snd-usb-audio MC support patch.
> I remember Shuah reported something similar on that time.
> 
> > Allocating struct media_device dynamically
> > --
> > 
> > Traditionally the media device has been allocated as part of drivers' own
> > structures. This is certainly fine as such, but many drivers have allocated
> > the driver private struct using the devm_() family of functions. This causes
> > such memory to be released at the time of device removal rather than at the
> > time when the memory is no longer accessible by e.g. user space processes or
> > interrupt handlers. Besides the media device, the driver's own data
> > structure is very likely to have the precisely same lifetime issue: it may
> > also be accessed through IOCTLs after the device has been removed from the
> > system.
> > 
> > Instead, the memory needs to be released as part of the release() callback
> > of the media device which is called when the last reference to the media
> > device is gone. Still, allocating the media device outside another
> > containing driver specific struct will be required in some cases: sharing
> > the media device mandates that. Implementing this can certainly be postponed
> > until sharing the media device is otherwise supported as well.
> 
> The patches adding MC support for snd-usb-audio, pending since Kernel
> 4.7 (I guess) require such functionatilty. Last year, on the audio
> summit, they asked about its status, as they're needing MC suppor there.
> 
> So, whatever solution taken, this should be part of the solution.
> 
> (c/c Shuah, as she is the one working on it)

I think we should postpone that, or at least resolve that in a separate
patchset. This is already getting very big. The refcounting problems will be
harder to fix, should we extend the MC framework with media device sharing
without considering the object lifetime issues first. So the order should
be: first fix object lifetime issues, then add more features.

Matters unrelated to the object lifetime issues such as the device (driver)
specific fields in struct media_device need to be addressed before support
for sharing the media device can be implemented. That work can be done
independently of fixing the object lifetime issues.

Implemeting media device sharing 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Mauro Carvalho Chehab]

Hi Sakari/Hans/Laurent,

First of all, thanks for looking into those issues. Unfortunately, I was in
vacations, and were not able to be with you there for such discussions.

While I have a somewhat different view on some of the introductory points of 
this RFC, what really matters is the "proposal" part of it. So, based on the
experiments I did when I addressed the hotplug issues with the media
controller on USB drivers, I'm adding a few comments below.


Em Fri, 27 Jan 2017 12:08:22 +0200
Sakari Ailus  escreveu:

> Allocating struct media_devnode separately from struct media_device
> ---
> 
> The current codebase allocates struct media_devnode dynamically. This was
> done in order to reduce the time window during which unallocated kernel
> memory could be accessed. However, there is no specific need for such a
> separation as the entire data structure, including the media device which
> used to contain struct media_devnode, will have the same lifetime. Thus the
> struct media_devnode should be allocated as part of struct media_device.
> Later on, struct media_devnode may be merged with struct media_device if so
> decided.

There is one issue merging struct media_devnode at struct media_device.
The problem is that, if the same struct device is used for two different
APIs (like V4L2 and media_controller) , e. g. if the cdev parent points
to the same struct device, you may end by having a double free when the
device is unregistered on the second core. That's basically why 
currently struct cdev is at struct media_devnode: this way, it has its own
struct device.

IMHO, it also makes sense to embeed struct cdev at the V4L2 side, as I
detected some race issues at the V4L2 side when I ran the bind/unbind
race tests, when we tried to merge the snd-usb-audio MC support patch.
I remember Shuah reported something similar on that time.

> Allocating struct media_device dynamically
> --
> 
> Traditionally the media device has been allocated as part of drivers' own
> structures. This is certainly fine as such, but many drivers have allocated
> the driver private struct using the devm_() family of functions. This causes
> such memory to be released at the time of device removal rather than at the
> time when the memory is no longer accessible by e.g. user space processes or
> interrupt handlers. Besides the media device, the driver's own data
> structure is very likely to have the precisely same lifetime issue: it may
> also be accessed through IOCTLs after the device has been removed from the
> system.
> 
> Instead, the memory needs to be released as part of the release() callback
> of the media device which is called when the last reference to the media
> device is gone. Still, allocating the media device outside another
> containing driver specific struct will be required in some cases: sharing
> the media device mandates that. Implementing this can certainly be postponed
> until sharing the media device is otherwise supported as well.

The patches adding MC support for snd-usb-audio, pending since Kernel
4.7 (I guess) require such functionatilty. Last year, on the audio
summit, they asked about its status, as they're needing MC suppor there.

So, whatever solution taken, this should be part of the solution.

(c/c Shuah, as she is the one working on it)

> Lifetime of the media entities and related framework or driver objects
> ==
> 
> The media graph data structure is a complex data structure consisting of
> media graph objects that themselves may be either entities, links or pads.
> The media graph objects are allocated by various drivers and currently have
> a lifetime related to binding and unbinding of the related hardware. The
> current rules (i.e. acquiring the media graph lock for graph traversal) are
> not enough to properly support removing entities.
> 
> Instead, reference counting needs to be introduced for media entities and
> other objects that contain media entities. References must be acquired (or
> in some cases, borrowed) whenever a reference is held to an object. A
> release callback is used to release the memory allocation that contains an
> object when the last reference to the object has been put. For instance:
> 
>   struct media_entity {
>   ...
>   struct kref kref;
>   void (*release)(struct media_entity *entity);
>   };

The similar rationale is valid also for media interfaces and, on a
lesser extent, to pads and links.

So, instead, IMHO, the kref should be implemented at struct media_gobj,
with is inherited by all graph elements. I guess that handling it
there will avoid us to duplicate the same logic on different
places (e. g. interface and entity logic handling; links handling).

Btw, as you want to use OMAP3 as a reference driver, you should
implement 

Re: [ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

On Fri, Jan 27, 2017 at 12:08:22PM +0200, Sakari Ailus wrote:
> 2016-01-13

As the most attentive of you have noticed, this should have been 2017-01-13.
The New Year just doesn't always take effect immediately. :-)

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANN] Media object lifetime management meeting report from Oslo

[Sakari Ailus]

Hello everyone,

Please read below my report on resolving object lifetime issues in V4L2 and
Media controller frameworks. The document is rather long but worth reading if
you're interested in the topic.


Sakari Ailus, Laurent Pinchart and Hans Verkuil present
2016-01-13


Introduction to the problem domain
==

The Media controller framework was first used for complex devices with
internal data processing pipelines. The problem domain that got most of the
attention as how the pipeline configuration would work and how V4L2
sub-device format would be propagated or how the pipeline validation would
work. As none of the devices that were supported in the beginning were
hot-pluggable, little attention was paid in making it possible to remove
them.

The media graph is a complex, highly interconnected data structure with
object allocated by different drivers and with different lifetimes. The data
structure can be navigated by the Media controller framework and by drivers,
including parts that those drivers did not create themselves. While some
rules exist on how this could be done, for instance the graph traversal,
these rules are not enough to support new use cases such as hot-pluggable
devices (or safely unbinding devices in general).

In the original (and also the current) implementation of the Media
controller framework tearing down a Media device was centered in the ability
of removing devices without crashing the kernel while the said devices were
not in use by a user application. In order to prevent unbinding drivers,
module use counts are increased whilst the devices are in use. This
obviously does not guarantee that: hot-pluggable devices may be removed
without the user application even knowing it, as well as non-hotpluggable
devices may also be unbound even if the module stays loaded (of which the
latter is certainly a lesser concern).


Current and future issues
=

* Media device lifetime management. There is no serialisation between
  issuing system calls to the media device driver and removing the struct
  media_device from the system, typically through unbinding a device from
  the driver. This leaves a time window in which released kernel memory may
  be accessed.

* Media entity lifetime management (including driver allocated objects that
  can be reached through media graph objects). Media entities (and objects
  that embed media graph objects) may be looked up by drivers and
  referenced. Such references may be kept for an extended period of time.
  Sub-device drivers may call other sub-devices' operations as well as they
  may be accessed from the user space through file handles. Media entity
  lifetime management is required for safely removing them.

* Sharing a struct media_device between drivers. This is not a problem right
  now but will need to be addressed before a struct media_device may be
  shared between multiple drivers. Currently, the struct media_device has
  multiple fields that are specific to a single driver which inherently
  makes a media device non-shareable:

- dev: struct device of the bridge/ISP driver
- ops: ops structure that contains e.g. link_setup used for managing
  power across the pipelines found in a media device. In the future,
  this would include routing configuration as well.

  The functionality supported by these fields has to be implemented by means
  supporting multiple drivers before sharing the struct media_device is
  possible. In that solution, these fields may not continue to exist in the
  form they do now.


General rules for accessing data and running code
=

These rules must be followed in accessing data and executing code in all
cases:

code) While there is a chance to execute code, the containing module
  reference count must be incremented.

data) Every memory allocation must be reference counted if a pointer to
  that memory is being shared. Each user obtains a reference and puts it
  using a related put function which will release the memory if it was the
  last reference.


Object reference counting golden rules
==

1. When a pointer to a reference-counted object is stored for later use, a
   reference to that object must exist.

2. A reference exists if it is taken or borrowed.

3. A borrowed reference is a reference taken elsewhere that can be proven to
   exist for the complete lifetime of the pointer.

4. When in doubt about whether a reference can be borrowed, it can be taken
   without any adverse impact.

5. A reference taken must be put at some point.

6. No access to a pointer can occur after the corresponding reference has
   been put.

6.1. The point when the reference is put must be proven to occur
 later than all other possible accesses to the reference.

6.2. At the location where the reference is put, care must be taken