On Thu, Nov 3, 2011 at 11:40 PM, Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote: > Hi, > > On 11/03/2011 05:32 PM, Lin Ming wrote: >> On Thu, 2011-11-03 at 18:48 +0800, Rakib Mullick wrote: >>> Calling pm-suspend might trigger a recursive lock in it's code path. In function acpi_hw_clear_acpi_status, >> >> As I replied at https://lkml.org/lkml/2011/9/22/6, I still don't think >> there is a recursive lock. >> > > At first look, it definitely doesn't look like a recursive lock, as Lin said. > But, quoting Documentation/lockdep-design.txt: > > "Multi-lock dependency rules: > ---------------------------- > > The same lock-class must not be acquired twice, because this could lead > to lock recursion deadlocks." > > So, Rakib, do the 2 locks belong to the same lock-class? If yes, then I think > that is the reason for the lockdep splat. Could you show the lockdep warning? > Yes, same lock-class. And as per "Multi-lock dependency rules:", it leads to lock recursion deadlocks. Lockdep warning attached. > By the way, another way to look at this patch is as an optimization.. > i.e., if acpi_gbl_hardware_lock doesn't need to be held to call > acpi_ev_walk_gpe_list(), then we can move from the coarse-grained locking > to finer-grained locking by releasing it earlier, as you did in your patch. > [Note that you will have to update the goto label also, i.e., rename it as > 'exit' or something like that] > I can do it, thanks for suggestions. But, what does Lin thinks? Lin are you okay? Thanks, Rakib
Attachment:
lockdepwarning
Description: Binary data
