linux-kernel - Re: [Bug 3.14.17] inconsistent lock state

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]

Date:	Mon, 25 Aug 2014 11:43:05 +0800
From:	Lan Tianyu <tianyu.lan@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Knut Petersen <Knut_Petersen@...nline.de>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Thomas Renninger <trenn@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Bug 3.14.17] inconsistent lock state

On 2014年08月25日 11:13, Linus Torvalds wrote:
> On Sun, Aug 24, 2014 at 7:53 PM, Lan Tianyu <tianyu.lan@...el.com> wrote:
>>
>> Sorry about this. We are resolving the issue in the other bug
>> report(https://lkml.org/lkml/2014/8/21/606) and I have proposed a fix
>> patch(http://marc.info/?l=linux-acpi&m=140869309231199&w=2).
> 
> Ahh. Good. That patch looks fine to me, and while it makes me worry a
> bit that some codepath expects the power/sleep button to be handled
> immediately in interrupt context, I guess the actual callbacks have
> never actually done anything but schedule other things to happen (ie
> add events to some queue), and making the context be the same as the
> other notify callbacks would seem to be a good thing regardless of
> this particular bug.

Yes, I have the same opinion and the callback just reports power/sleep
button event to user space via input layer or ACPI netlink routines.

The button devices enumerated from ACPI namespace and FADT table share
the same notify callback and do the same things while they are running
different context. This seems not make sense.

> 
> Knut - can you please test the patch Lan pointed at? I realize it
> doesn't seem to be entirely consistent for you (which is a bit
> surprising, I wonder why lockdep doesn't trigger it consistently), but
> it would be good to have more testing. Even if that patch looks
> "obviously good" (tm) at a quick glance.

BTW, this bug only takes place on the machines with fixed button device.
This can be identified via check whether there are LNXPWRBN:00 or
LNXSLPBN:00 device nodes under /sys/bus/acpi/devices.

> 
>                   Linus
> 


-- 
Best regards
Tianyu Lan
--
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/