From: Jan Engelhardt <jengelh@inai.de>
To: "Kaneda, Erik" <erik.kaneda@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
"Moore, Robert" <robert.moore@intel.com>,
"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] acpica: clear global_lock bits at FACS initialization
Date: Thu, 2 Apr 2020 02:13:12 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2004020156480.16288@n3.vanv.qr> (raw)
In-Reply-To: <CY4PR11MB171939B742CF12CD476E6BCEF0C90@CY4PR11MB1719.namprd11.prod.outlook.com>
On Wednesday 2020-04-01 23:55, Kaneda, Erik wrote:
>
>I've been reading the ACPI spec and there's nothing stated about what the
>initial state of the lock should be... This patch is assuming that the lock should
>be free when the FACS is being initialized and I don't think this is a safe
>assumption to make.
>
>What if this is a legitimate acquisition by an SMI handler very early in OS boot?
Before the OS has initialized ACPI (which, to me, is best recognized by what
action the power button will cause - either instant-off or ACPI event),
I would imagine that there are no SMI handlers that try to make use of ACPI
features like the FACS lock.
Furthermore, if the OS has taken the FACS lock and an SMI happens,
what would the SMI do if it cannot obtain the lock? It certainly can't
busywait for the OS, because that's interrupted..
>> > When the firmware ROM supplies a FACS table with garbage, and the
>> > firmware code does not clear the global_lock field before booting to a
>> > loader/OS, the garbage bytes in that field (like 0xffffffff) can
>> > indicate that the lock is taken when it is not, thereby preventing
>> > obtaining said lock even though it is otherwise perfectly usable if
>> > the field were not prepopulated with garbage.
>
>How do we know that the lock is taken when it is not?
We don't. ACPI does not make itself look good in this instance I am afraid.
next prev parent reply other threads:[~2020-04-02 0:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 8:58 [PATCH] acpica: clear global_lock bits at FACS initialization Jan Engelhardt
2020-04-01 9:11 ` Rafael J. Wysocki
2020-04-01 21:55 ` Kaneda, Erik
2020-04-02 0:13 ` Jan Engelhardt [this message]
2020-04-02 11:28 ` Dan Carpenter
2020-04-02 11:28 ` Dan Carpenter
2020-04-02 11:28 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YFH.7.76.2004020156480.16288@n3.vanv.qr \
--to=jengelh@inai.de \
--cc=erik.kaneda@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.