linux-kernel - Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

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: <CA+55aFzmL0FTp_w7RWA0+mqS7YBL5HoNS1WY=2zxURgnvkOcjw@mail.gmail.com>
Date:	Mon, 9 Jan 2012 11:41:44 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Rogério Brito <rbrito@....usp.br>,
	bugzilla-daemon@...zilla.kernel.org,
	Edward Donovan <edward.donovan@...ble.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-kernel@...r.kernel.org,
	Márcia Coutinho de Brito <mcbrito@...il.com>,
	Yinghai Lu <yinghai@...nel.org>, Ram Pai <linuxram@...ibm.com>
Subject: Re: [Bug 41722] Clevo M5X0JE hangs in ACPI init

On Mon, Jan 9, 2012 at 11:22 AM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
>
> I don't remember what problems we hit, but if Ram and Yinghai are
> willing to take a look at them we should go ahead and try again.

So the two bugzilla entries quoted in the revert are

  http://bugzilla.kernel.org/show_bug.cgi?id=10080
  http://bugzilla.kernel.org/show_bug.cgi?id=9961

 with at least one real smoking gun in this one:

  https://lkml.org/lkml/2008/3/26/94

however at least *part* of the problem for some people was not the
transparency itself, as much as the fact that we did bad things with
64-bit resources etc.

So what I think mostly happened was that not sizing up transparent
bridges ended up showing up other bugs. We've fixed at least some of
those other bugs in the meantime (things like using "unsigned long"
for physical addresses in ioremap etc, which broke when 64-bit
resources were used on 32-bit architectures).

But it's entirely possible that it will still trigger similar issues.
For example, even if a bridge is transparent, maybe it is still
limited to 32-bit addresses? If we look at the actual IO windows, we'd
get that 32-bit limit right automatically. If we just say "it's
transparent", we might allocate child devices with 64-bit resources
above the 4GB area, and be screwed. That seems to have been one
problem above - even if we now get it right on a software level, there
may actually be hardware issues in the same area.

(It's not clear whether the 64-bit resource issue back in 2008 was due
to hardware or due to our resource bugs).

Adding Ivan to the cc due to historical issues - although I haven't
seen him in email for a year, so he may be gone.

                           Linus
--
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/