Message-ID: <20190630114102.GB7043@pendragon.ideasonboard.com>
Date:   Sun, 30 Jun 2019 14:41:02 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Shuah Khan <skhan@...uxfoundation.org>
Cc:     Helen Koike <helen.koike@...labora.com>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Use Media Dev Allocator to fix vimc dev lifetime bugs

Hi Shuah,

On Fri, Jun 28, 2019 at 10:41:07AM -0600, Shuah Khan wrote:
> On 6/16/19 12:45 PM, Laurent Pinchart wrote:
> > On Fri, Jun 14, 2019 at 05:26:46PM -0600, Shuah Khan wrote:
> >> On 6/13/19 7:24 AM, Helen Koike wrote:
> >>> On 6/13/19 2:44 AM, Hans Verkuil wrote:
> >>>> On 5/24/19 5:31 AM, Shuah Khan wrote:
> >>>>> media_device is embedded in struct vimc_device and when vimc is removed
> >>>>> vimc_device and the embedded media_device goes with it, while the active
> >>>>> stream and vimc_capture continue to access it.
> >>>>>
> >>>>> Fix the media_device lifetime problem by changing vimc to create shared
> >>>>> media_device using Media Device Allocator API and vimc_capture getting
> >>>>> a reference to vimc module. With this change, vimc module can be removed
> >>>>> only when the references are gone. vimc can be removed after vimc_capture
> >>>>> is removed.
> >>>>>
> >>>>> Media Device Allocator API supports just USB devices. Enhance it
> >>>>> adding a genetic device allocate interface to support other media
> >>>>> drivers.
> >>>>>
> >>>>> The new interface takes pointer to struct device instead and creates
> >>>>> media device. This interface allows a group of drivers that have a
> >>>>> common root device to share media device resource and ensure media
> >>>>> device doesn't get deleted as long as one of the drivers holds its
> >>>>> reference.
> >>>>>
> >>>>> The new interface has been tested with vimc component driver to fix
> >>>>> panics when vimc module is removed while streaming is in progress.
> >>>>
> >>>> Helen, can you review this series? I'm not sure this is the right approach
> >>>> for a driver like vimc, and even if it is, then it is odd that vimc-capture
> >>>> is the only vimc module that's handled here.
> >>>
> >>> Hi Hans,
> >>>
> >>> Yes, I can take a look. Sorry, I've been a bit busy these days but I'll
> >>> try to take a look at this patch series (and the others) asap.
> >>>
> >>> Helen
> >>>
> >>>> My gut feeling is that this should be handled inside vimc directly and not
> >>>> using the media-dev-allocator.
> >>
> >> Hi Hans and Helen,
> >>
> >> I explored fixing the problem within vimc before I went down the path to
> >> use Media Device Allocator API. I do think that it is cleaner to go this
> >> way and easier to maintain.
> >>
> >> vimc is a group pf component drivers that rely on the media device vimc
> >> in vimc and falls into the use-case Media Device Allocator API is added
> >> to address. The release and life-time management happens without vimc
> >> component drivers being changed other than using the API to get and put
> >> media device reference.
> > 
> > Our replies crossed each other, please see my reply to Hans. I would
> > just like to comment here that if having multiple kernel modules causes
> > issue, they can all be merged together. There's no need for vimc to be
> > handled through multiple modules (I actually think it's quite
> > counterproductive, it only makes it more complex, for no added value).
> 
> There are several problems in this group of drivers as far as lifetime
> management is concerned. I explained some of it in the patch 2/2
> 
> If vimc module is removed while streaming is active, vimc_exit runs
> into NULL pointer dereference error when streaming thread tries to
> access and lock graph_mutex in the struct media_device.
> 
> The primary reason for this is that:
> 
> media_device is embedded in struct vimc_device and when vimc is removed
> vimc_device and the embedded media_device goes with it, while the active
> stream and vimc_capture continue to access it.

The issue isn't so much that media_devic is embedded in vimc_device, but
that vimc_device is released too early. Not only does the thread need to
access the graph_mutex lock in the media_device structure, but it can
potentially access fields of the device-specific structures as well. The
proper solution is to propagate media_device_release() one level up, in
order to only release the top-level structure containing media_device
when the last reference to the media_device is dropped.

> If we chose to keep these drivers as component drivers, media device
> needs to stick around until all components stop using it. This is tricky
> because there is no tie between these set of drivers. vimc module can
> be deleted while others are still active. As vimc gets removed, other
> component drivers start wanting to access the media device tree.

Reference-counting is the key.

> This is classic media device lifetime problem which could be solved
> easily with the way I solved it with this series. I saw this as a
> variation on the same use-case we had with sound and media drivers
> sharing the media device.

This isn't about solving it easily, it's about solving it properly. The
media device allocator as used here is a hack and takes us in the
opposite direction of a proper fix.

> I have a TODO request from you asking to extend Media Device Allocator
> API to generic case and not restrict it to USB devices. My thinking is
> that this gives a perfect test case to extend the API to be generic
> and use to solve this problem.

The biggest issue at the moment with the media device allocator, which I
have pointed out numerous times and has never been addressed (and which
explains why I didn't think the code was ready to be merged) is that the
media_device contains operations that are based on having a single
driver controlling the media device. A proper shared media device
allocator needs to drop the concept of a single master for the media
device, and thus needs to refactor those operations to allow any user of
the media device to implement them (the .link_notify() operation is a
prime example, and the recently added request operations will make this
even more challenging - think of how this patch series would prevent
vimc from properly implementing the request API). As long as these issue
are not fixed I will be firmly opposed to spreading the usage of the
media device allocator beyond what exists today.

> Collapsing the drivers into one might be lot more difficult and complex
> than solving this problem with Media Device Allocator API. This approach
> has an added benefit of extending the API to be generic and not just for
> USB.

I've never disputed the fact that fixing a problem correctly is usually
more work than hacking around it :-)

> I looked at this as a good way to add generic API and have a great test
> case for it. This patch series fixes the problem for the current vimc
> architecture.

NAK, for the reasons above. Please drop this series and fix the problem
properly.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists