On Thu, Sep 22, 2011 at 10:28 AM, Lin Ming <ming.m.lin@xxxxxxxxx> wrote: > On Thu, 2011-09-22 at 11:35 +0800, Rakib Mullick wrote: >> On Thu, Sep 22, 2011 at 6:59 AM, Lin Ming <ming.m.lin@xxxxxxxxx> wrote: >> > On Thu, Sep 22, 2011 at 2:09 AM, Rakib Mullick <rakib.mullick@xxxxxxxxx> wrote: >> >> Calling pm-suspend might trigger a recursive lock in it's code path. In function acpi_hw_clear_acpi_status, >> >> acpi_os_release_lock holds the lock acpi_gbl_hardware_lock before calling acpi_hw_register_write(), then >> >> without releasing acpi_gbl_hardware_lock, this function calls acpi_ev_walk_gpe_list, which also tries to >> >> hold acpi_gbl_hardware_lock and thus causes possible recursive lock. >> > >> > No, acpi_ev_walk_gpe_list holds acpi_gbl_gpe_lock. >> > >> Yes, right. Actually, acpi_os_release_lock() tries to hold >> acpi_gbl_gpe_lock without releasing acpi_gbl_hardware_lock. Right? > > Do you mean "acpi_ev_walk_gpe_list() tries to hold > acpi_gbl_gpe_lock..."? > I wanted to mean, acpi_os_acquire_lock() tries to hold acpi_gbl_gpe_lock without releasing acpi_gbl_hardware_lock. Actually, this recursive locking scenario showed up on my modified kernel and fails to suspend. But, never happened on mainline kernel. Looking at the warning it seems to me that, it's safe to release the acpi_gbl_hardware_lock before calling acpi_ev_walk_gpe_list() and also solves the problem. Calling acpi_ev_walk_gpe_list() doesn't require acpi_gbl_hardware_lock to be held. This is the reason behind the patch. > We have below locks sequence. I don't see the problem. > > acpi_hw_clear_acpi_status: > > <acquire acpi_gbl_hardware_lock> > > acpi_ev_walk_gpe_list: > <acquire acpi_gbl_gpe_lock> > ... > <release acpi_gbl_gpe_lock> > ... > <release acpi_gbl_hardware_lock> > >> >> Thanks, >> Rakib > > > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
