mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Michael K. Johnson" <johnsonm@rpath.com>,
	Justin Forbes <jmforbes@linuxtx.org>,
	Jordan Hargrave <Jordan_Hargrave@dell.com>,
	Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] x86 setup BIOS workarounds
Date: Wed, 1 Apr 2009 11:24:10 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.0904011115210.4130@localhost.localdomain> (raw)
In-Reply-To: <200904011640.n31GeD0m008691@voreg.hos.anvin.org>



On Wed, 1 Apr 2009, H. Peter Anvin wrote:
> 
> implements handling for the backwards-incompatible(!) E820 handling in 
> ACPI 3.

I am _extremely_ nervous about this one.

You do

	size = sizeof buf;	/* ACPI-3 size */
	asm(.. "+c" (size)	/* size might change */
	..
	if (size > 20 && !(buf.ext_flags & 1))
		continue;

ie you are expecting that _all_ old pre-ACPI-3 BIOSES will always set size 
to 20, or always write a low-bit-set value to that extended flag field 
that doesn't even exist previously.

I don't think that's likely true. Quite frankly, I'd expect a number of 
BIOSen to entirely ignore %ecx, since it's irrelevant (it _has_ to be 
bigger than 20 anyway on entry, and I doubt anybody really ever bothered 
to test that it's 20 on exit).

So at a _minimum_, I'd suggest that we set bug.ext_flags to 1 before the 
call - so that if some random BIOS just leaves %ecx unchanged, it won't 
mean that the area just gets ignored as a ACPI-3 entry.

And if it really _is_ a new ACPI-3 BIOS, it will overwrite ext_flags with 
its own value.

I've pulled you changes, but I really don't like how they seem to be 
designed to be very fragile, and designed to expect BIOSes to actually 
implement documented interfaces without bugs. So please look at it.

		Linus

  reply	other threads:[~2009-04-01 18:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-27 17:14 [PATCH] mark %esi as clobbered in E820 BIOS call Michael K. Johnson
2009-03-28 11:20 ` Ingo Molnar
2009-03-28 19:18   ` H. Peter Anvin
2009-04-01 16:40 ` [GIT PULL] x86 setup BIOS workarounds H. Peter Anvin
2009-04-01 18:24   ` Linus Torvalds [this message]
2009-04-01 18:51     ` H. Peter Anvin
2009-04-02  4:26     ` Len Brown
2009-04-02 19:31       ` Linus Torvalds
2009-04-02  4:15   ` Len Brown
2009-04-02 20:07     ` H. Peter Anvin

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=alpine.LFD.2.00.0904011115210.4130@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=Jordan_Hargrave@dell.com \
    --cc=hpa@zytor.com \
    --cc=jmforbes@linuxtx.org \
    --cc=johnsonm@rpath.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome