linux-toradex.git/arch/x86, branch v2.6.28.6

x86: microcode_amd: fix wrong handling of equivalent CPU id

2009-02-17T17:29:05+00:00

commit 3c763fd77e66e55d029052da31df0abd9920cb1e upstream.

Impact: fix bug resulting in non-loaded AMD microcode

mc_header->processor_rev_id is a 2 byte value. Similar is true for
equiv_cpu in an equiv_cpu_entry -- only 2 bytes are of interest.

Signed-off-by: Andreas Herrmann 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, vmi: put a missing paravirt_release_pmd in pgd_dtor

2009-02-17T17:28:43+00:00

commit 55a8ba4b7f76bebd7e8ce3f74c04b140627a1bad upstream.

Commit 6194ba6ff6ccf8d5c54c857600843c67aa82c407 ("x86: don't special-case
pmd allocations as much") made changes to the way we handle pmd allocations,
and while doing that it dropped a call to  paravirt_release_pd on the
pgd page from the pgd_dtor code path.

As a result of this missing release, the hypervisor is now unaware of the
pgd page being freed, and as a result it ends up tracking this page as a
page table page.

After this the guest may start using the same page for other purposes, and
depending on what use the page is put to, it may result in various performance
and/or functional issues ( hangs, reboots).

Since this release is only required for VMI, I now release the pgd page from
the (vmi)_pgd_free hook.

Signed-off-by: Alok N Kataria 
Acked-by: Jeremy Fitzhardinge 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: APIC: enable workaround on AMD Fam10h CPUs

2009-02-12T17:50:27+00:00

commit 858770619debfb9269add63e4ba8b7c6b5538dd1 upstream.

Impact: fix to enable APIC for AMD Fam10h on chipsets with a missing/b0rked
	ACPI MP table (MADT)

Booting a 32bit kernel on an AMD Fam10h CPU running on chipsets with
missing/b0rked MP table leads to a hang pretty early in the boot process
due to the APIC not being initialized. Fix that by falling back to the
default APIC base address in 32bit code, as it is done in the 64bit
codepath.

Signed-off-by: Borislav Petkov 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

prevent kprobes from catching spurious page faults

2009-02-12T17:50:24+00:00

commit 9be260a646bf76fa418ee519afa10196b3164681 upstream.

Prevent kprobes from catching spurious faults which will cause infinite
recursive page-fault and memory corruption by stack overflow.

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI: Avoid array address overflow when _CST MWAIT hint bits are set

2009-02-06T21:47:23+00:00

commit 13b40a1a065824d2d4e55c8b48ea9f3f9d162929 upstream.

The Cx Register address obtained from the _CST object is used as the MWAIT
hints if the register type is FFixedHW. And it is used to check whether
the Cx type is supported or not.

On some boxes the following Cx state package is obtained from _CST object:
    >{
                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x01,               // Bit Width
                        0x02,               // Bit Offset
                        0x0000000000889759, // Address
                        0x03,               // Access Size
                        )
                },

                0x03,
                0xF5,
                0x015E }

   In such case we should use the bit[7:4] of Cx address to check whether
the Cx type is supported or not.

mask the MWAIT hint to avoid array address overflow

Signed-off-by: Zhao Yakui 
Acked-by:Venki Pallipadi 
Signed-off-by: Len Brown 
Cc: Thomas Renninger

PCI: irq and pci_ids patch for Intel Tigerpoint DeviceIDs

2009-02-06T21:47:23+00:00

commit 57064d213d2e44654d4f13c66df135b5e7389a26 upstream.

This patch adds the Intel Tigerpoint LPC Controller DeviceIDs.

Signed-off-by: Seth Heasley 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86: use early clobbers in usercopy*.c

2009-02-06T21:47:17+00:00

commit e0a96129db574d6365e3439d16d88517c437ab33 upstream.

Impact: fix rare (but currently harmless) miscompile with certain configs and gcc versions

Hugh Dickins noticed that strncpy_from_user() was miscompiled
in some circumstances with gcc 4.3.

Thanks to Hugh's excellent analysis it was easy to track down.

Hugh writes:

> Try building an x86_64 defconfig 2.6.29-rc1 kernel tree,
> except not quite defconfig, switch CONFIG_PREEMPT_NONE=y
> and CONFIG_PREEMPT_VOLUNTARY off (because it expands a
> might_fault() there, which hides the issue): using a
> gcc 4.3.2 (I've checked both openSUSE 11.1 and Fedora 10).
>
> It generates the following:
>
> 0000000000000000 <__strncpy_from_user>:
>    0:   48 89 d1                mov    %rdx,%rcx
>    3:   48 85 c9                test   %rcx,%rcx
>    6:   74 0e                   je     16 <__strncpy_from_user+0x16>
>    8:   ac                      lods   %ds:(%rsi),%al
>    9:   aa                      stos   %al,%es:(%rdi)
>    a:   84 c0                   test   %al,%al
>    c:   74 05                   je     13 <__strncpy_from_user+0x13>
>    e:   48 ff c9                dec    %rcx
>   11:   75 f5                   jne    8 <__strncpy_from_user+0x8>
>   13:   48 29 c9                sub    %rcx,%rcx
>   16:   48 89 c8                mov    %rcx,%rax
>   19:   c3                      retq
>
> Observe that "sub %rcx,%rcx; mov %rcx,%rax", whereas gcc 4.2.1
> (and many other configs) say "sub %rcx,%rdx; mov %rdx,%rax".
> Isn't it returning 0 when it ought to be returning strlen?

The asm constraints for the strncpy_from_user() result were missing an
early clobber, which tells gcc that the last output arguments
are written before all input arguments are read.

Also add more early clobbers in the rest of the file and fix 32-bit
usercopy.c in the same way.

Signed-off-by: Andi Kleen 
Signed-off-by: H. Peter Anvin 
[ since this API is rarely used and no in-kernel user relies on a 'len'
  return value (they only rely on negative return values) this miscompile
  was never noticed in the field. But it's worth fixing it nevertheless. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, pat: fix PTE corruption issue while mapping RAM using /dev/mem

2009-02-02T17:53:28+00:00

commit 9597134218300c045cf219be3664615e97cb239c upstream.

Beschorner Daniel reported:
> hwinfo problem since 2.6.28, showing this in the oops:
>   Corrupted page table at address 7fd04de3ec00

Also, PaX Team reported a regression with this commit:

>   commit 9542ada803198e6eba29d3289abb39ea82047b92
>   Author: Suresh Siddha 
>   Date:   Wed Sep 24 08:53:33 2008 -0700
>
>       x86: track memtype for RAM in page struct

This commit breaks mapping any RAM page through /dev/mem, as the
reserve_memtype() was not initializing the return attribute type and as such
corrupting the PTE entry that was setup with the return attribute type.

Because of this bug, application mapping this RAM page through /dev/mem
will die with "Corrupted page table at address xxxx" message in the kernel
log and also the kernel identity mapping which maps the underlying RAM
page gets converted to UC.

Fix this by initializing the return attribute type before calling
reserve_ram_pages_type()

Reported-by: PaX Team 
Reported-and-tested-by: Beschorner Daniel 
Tested-and-Acked-by: PaX Team 
Signed-off-by: Suresh Siddha 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, pat: fix reserve_memtype() for legacy 1MB range

2009-02-02T17:53:28+00:00

commit 5cca0cf15a94417f49625ce52e23589eed0a1675 upstream
 
Thierry Vignaud reported:
> http://bugzilla.kernel.org/show_bug.cgi?id=12372
>
> On P4 with an SiS motherboard (video card is a SiS 651)
> X server fails to start with error:
> xf86MapVidMem: Could not mmap framebuffer (0x00000000,0x2000) (Invalid
> argument)

Here X is trying to map first 8KB of memory using /dev/mem. Existing
code treats first 0-4KB of memory as non-RAM and 4KB-8KB as RAM. Recent
code changes don't allow to map memory with different attributes
at the same time.

Fix this by treating the first 1MB legacy region as special and always
track the attribute requests with in this region using linear linked
list (and don't bother if the range is RAM or non-RAM or mixed)

Reported-and-tested-by: Thierry Vignaud 
Signed-off-by: Suresh Siddha 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix page attribute corruption with cpa()

2009-02-02T17:53:20+00:00

commit a1e46212a410793d575718818e81ddc442a65283 upstream.

Impact: fix sporadic slowdowns and warning messages

This patch fixes a performance issue reported by Linus on his
Nehalem system. While Linus reverted the PAT patch (commit
58dab916dfb57328d50deb0aa9b3fc92efa248ff) which exposed the issue,
existing cpa() code can potentially still cause wrong(page attribute
corruption) behavior.

This patch also fixes the "WARNING: at arch/x86/mm/pageattr.c:560" that
various people reported.

In 64bit kernel, kernel identity mapping might have holes depending
on the available memory and how e820 reports the address range
covering the RAM, ACPI, PCI reserved regions. If there is a 2MB/1GB hole
in the address range that is not listed by e820 entries, kernel identity
mapping will have a corresponding hole in its 1-1 identity mapping.

If cpa() happens on the kernel identity mapping which falls into these holes,
existing code fails like this:

	__change_page_attr_set_clr()
		__change_page_attr()
			returns 0 because of if (!kpte). But doesn't
			set cpa->numpages and cpa->pfn.
		cpa_process_alias()
			uses uninitialized cpa->pfn (random value)
			which can potentially lead to changing the page
			attribute of kernel text/data, kernel identity
			mapping of RAM pages etc. oops!

This bug was easily exposed by another PAT patch which was doing
cpa() more often on kernel identity mapping holes (physical range between
max_low_pfn_mapped and 4GB), where in here it was setting the
cache disable attribute(PCD) for kernel identity mappings aswell.

Fix cpa() to handle the kernel identity mapping holes. Retain
the WARN() for cpa() calls to other not present address ranges
(kernel-text/data, ioremap() addresses)

Signed-off-by: Suresh Siddha 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman