linux-kernel - Re: [PATCH] acpi: Fix possible recursive locking in hwregs.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADZ9YHjheS-j9kLDjCe3LrxLOOJ24ZSGDCgMukPShorJRQzwNQ@mail.gmail.com>
Date:	Thu, 22 Sep 2011 11:14:49 +0600
From:	Rakib Mullick <rakib.mullick@...il.com>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Moore, Robert" <robert.moore@...el.com>
Subject: Re: [PATCH] acpi: Fix possible recursive locking in hwregs.c

On Thu, Sep 22, 2011 at 10:28 AM, Lin Ming <ming.m.lin@...el.com> 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@...el.com> wrote:
>> > On Thu, Sep 22, 2011 at 2:09 AM, Rakib Mullick <rakib.mullick@...il.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/