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
