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: <AANLkTinJhVj7sY6wC1tFRA+rYW72j7GqKvxfRsyRC=Vs@mail.gmail.com>
Date:	Thu, 2 Dec 2010 17:19:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, Matthew Garrett <mjg@...hat.com>
Subject: Re: [PATCH] x86/PCI: never allocate PCI space from the last 1M below 4G

On Mon, Nov 29, 2010 at 2:04 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>
> I think we're talking about whether to reserve the top 1MB or top 2MB.
> I freely admit I don't know the right answer.  My point is merely that
> since we're using a heuristic anyway, copying Windows is a pretty good
> starting point.  In my mind, doing something different requires a
> stronger argument than "it might fix some machines where Windows is
> broken."

What's the status of this? The original patch is pretty nasty, and I
think that hack to put things in the bios_align_resource() function is
just disgusting.

And why is the fix not the really _trivial_ one, which does just this:

  diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
  index ca0437c..aef9f77 100644
  --- a/arch/x86/include/asm/pci.h
  +++ b/arch/x86/include/asm/pci.h
  @@ -141,7 +141,7 @@ void dma32_reserve_bootmem(void);

   /* generic pci stuff */
   #include <asm-generic/pci.h>
  -#define PCIBIOS_MAX_MEM_32 0xffffffff
  +#define PCIBIOS_MAX_MEM_32 0xfff00000

   #ifdef CONFIG_NUMA
   /* Returns the node based on pci bus */

Hmm?

(Ok, so that doesn't protect a 64-bit resource that just happens to be
inside a window that ends at 0xffffffff, but if you have those kinds
of bus windows, that means that there's nothing there at the 4GB mark
anyway, no?)

                     Linus

               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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ