linux-kernel - RE: [PATCH] ACPICA: don't cond_resched() when irq_disabled or in

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4911F71203A09E4D9981D27F9D83085840F38881@orsmsx503.amr.corp.intel.com>
Date:	Thu, 10 Dec 2009 14:54:47 -0800
From:	"Moore, Robert" <robert.moore@...el.com>
To:	"Justin P. Mattock" <justinmattock@...il.com>,
	Alexey Starikovskiy <aystarik@...il.com>
CC:	Pavel Machek <pavel@....cz>, Xiaotian Feng <dfeng@...hat.com>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Lin, Ming M" <ming.m.lin@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ACPICA: don't cond_resched() when irq_disabled or
 in_atomic

Let me know when you guys have finalized any changes to aclinux.h, and I will update this file in the base ACPICA code.

Bob


>-----Original Message-----
>From: Justin P. Mattock [mailto:justinmattock@...il.com]
>Sent: Thursday, December 10, 2009 2:46 PM
>To: Alexey Starikovskiy
>Cc: Pavel Machek; Xiaotian Feng; lenb@...nel.org; Lin, Ming M; Moore,
>Robert; linux-acpi@...r.kernel.org; linux-kernel@...r.kernel.org
>Subject: Re: [PATCH] ACPICA: don't cond_resched() when irq_disabled or
>in_atomic
>
>On 12/10/09 10:37, Alexey Starikovskiy wrote:
>> Pavel Machek пишет:
>>> On Thu 2009-12-10 20:58:45, Alexey Starikovskiy wrote:
>>>
>>>> Hi Pavel,
>>>>
>>>> Please elaborate... Your comments "ugly as hell" are too often to be
>>>> specific...
>>>> There is only one use of ACPI_PREEMPTION_POINT(), and it is in the
>>>> ACPICA code,
>>>> which we all agreed to keep OS independent, thus the need for #define.
>>>> Do you see any other way to add preemption point without introducing
>>>> Linux-specific
>>>> code into ACPICA?
>>>>
>>>
>>> I believe we want linux-specific code in acpica at this point.
>>>
>>>
>> The point there we call cond_resched() in ACPICA is an interpreter parse
>> loop. This parse loop may be executed from within atomic context and even
>> with interrupts off. In this case, cond_resched() should not be called
>> to not make
>> might_sleep() guards angry.
>>
>> Please post the code, which will do the above and will not look "ugly as
>> hell".
>> I still don't follow your vague comments.
>>> (Or maybe... I guess other systems have concept of preemption and not
>>> all actions are permitted from all contexts, so maybe something like
>>> that would be important for them, too?)
>>>
>> None of them cared about it up to this point.
>> With the macro above we allowed them to follow Linux, but to go or not
>> is their call.
>>
>> Regards,
>> Alex.
>> --
>> 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/
>>
>
>o.k. I went did a pull to update
>the kernel, and then changed
>aclinux.h to the above post.
>
>I'm am not seeing this warning message
>upon wake-up.
>but with the acpi merge stuff with
>acpi_walk_namespace seems to break nvidia
>(nvidia's problem now)
>
>there is also some thing where the machine
>takes a good 30 secs or so to wake up
>(not sure if this is from the updated patch)
>in dmesg I see:
>
>platform microcode: firmware requesting intel-ucode/06-17-0a
>firmware microcode: parent mocrocode should not be sleeping.
>
>I'm thinking I need something in /lib/firmare
>
>Justin P. Mattock
--
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/