Re: Possible regression in v4l2-async

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Steve, Niklas,

On Thu, Nov 29, 2018 at 11:41:32AM -0800, Steve Longerbeam wrote:
> 
> 
> On 11/29/18 11:26 AM, Steve Longerbeam wrote:
> > Hi Niklas,
> > 
> > On 11/29/18 10:47 AM, Niklas Söderlund wrote:
> > > Hi Steve, Sakari and Hans,
> > > 
> > > I have been made aware of a possible regression by a few users of
> > > rcar-vin and I'm a bit puzzled how to best handle it. Maybe you can help
> > > me out?
> > > 
> > > The issue is visible when running with LOCKDEP enabled and it prints a
> > > warning about a possible circular locking dependency, see end of mail.
> > > The warning is triggered because rcar-vin takes a mutex (group->lock) in
> > > its async bound call back while the async framework already holds one
> > > (lisk_lock).
> > 
> > I see two possible solutions to this:
> > 
> > A. Remove acquiring the list_lock in v4l2_async_notifier_init().
> > 
> > B. Move the call to v4l2_async_notifier_init()**to the top of
> > rvin_mc_parse_of_graph() (before acquiring group->lock).
> > 
> > It's most likely safe to remove the list_lock from
> > v4l2_async_notifier_init(), because all drivers should be calling that
> > function at probe start, before it begins to add async subdev
> > descriptors to their notifiers. But just the same, I think it would be
> > safer to keep list_lock in v4l2_async_notifier_init(), just in case of
> > some strange corner case (such as a driver that adds descriptors in a
> > separate thread from the thread that calls v4l2_async_notifier_init()).
> 
> Well, on second thought that's probably a lame example, no driver should be
> doing that. So removing the list_lock from v4l2_async_notifier_init() is
> probably safe. The notifier is not registered with v4l2-async at that point.

I agree, apart from "probably". It is safe.

Niklas: would you like to send a patch? :-)

-- 
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux