linux-toradex.git/arch, branch v2.6.33.16

um: os-linux/mem.c needs sys/stat.h

2011-07-13T03:31:26+00:00

commit fb967ecc584c20c74a007de749ca597068b0fcac upstream.

The os-linux/mem.c file calls fchmod function, which is declared in sys/stat.h
header file, so include it.  Fixes build breakage under FC13.

Signed-off-by: Liu Aleaxander 
Acked-by: Boaz Harrosh 
Cc: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

uml: fix CONFIG_STATIC_LINK=y build failure with newer glibc

2011-07-13T03:31:26+00:00

commit aa5fb4dbfd121296ca97c68cf90043a7ea97579d upstream.

With glibc 2.11 or later that was built with --enable-multi-arch, the UML
link fails with undefined references to __rel_iplt_start and similar
symbols.  In recent binutils, the default linker script defines these
symbols (see ld --verbose).  Fix the UML linker scripts to match the new
defaults for these sections.

Signed-off-by: Roland McGrath 
Cc: Jeff Dike 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"

2011-07-13T03:31:23+00:00

commit a91d92875ee94e4703fd017ccaadb48cfb344994 upstream.

We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to
make sure that cleanup_highmap doesn't remove important mappings at
_end.

We don't need to do this on x86_32 because cleanup_highmap is not called
on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted
side effect of limiting the amount of memory available for the 1:1
kernel pagetable allocation.

This patch reverts the x86_32 part of the original patch.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Fix boot crash with hidden PCI devices

2011-06-23T22:28:40+00:00

commit 26018874e3584f1658570d41d57d4c34f6a53aa0 upstream.

Some PCIe cards ship with a PCI-PCIe bridge which is not
visible as a PCI device in Linux. But the device-id of the
bridge is present in the IOMMU tables which causes a boot
crash in the IOMMU driver.
This patch fixes by removing these cards from the IOMMU
handling. This is a pure -stable fix, a real fix to handle
this situation appriatly will follow for the next merge
window.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Fix 3 possible endless loops

2011-06-23T22:28:40+00:00

commit 0de66d5b35ee148455e268b2782873204ffdef4b upstream.

The driver contains several loops counting on an u16 value
where the exit-condition is checked against variables that
can have values up to 0xffff. In this case the loops will
never exit. This patch fixed 3 such loops.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

x86/amd-iommu: Use only per-device dma_ops

2011-06-23T22:28:40+00:00

commit 27c2127a15d340706c0aa84e311188a14468d841 upstream.

Unfortunatly there are systems where the AMD IOMMU does not
cover all devices. This breaks with the current driver as it
initializes the global dma_ops variable. This patch limits
the AMD IOMMU to the devices listed in the IVRS table fixing
DMA for devices not covered by the IOMMU.

Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

xen: off by one errors in multicalls.c

2011-06-23T22:28:40+00:00

commit f124c6ae59e193705c9ddac57684d50006d710e6 upstream.

b->args[] has MC_ARGS elements, so the comparison here should be
">=" instead of ">".  Otherwise we read past the end of the array
one space.

Signed-off-by: Dan Carpenter 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

xen mmu: fix a race window causing leave_mm BUG()

2011-06-23T22:28:38+00:00

commit 7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream.

There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit 831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:

---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[]  [] leave_mm+0x15/0x46
RSP: e02b:ffff88002805be48  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0
RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200
R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880
R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000
FS:  00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40)
Stack:
 ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
 
 [] drop_other_mm_ref+0x2a/0x53
 [] generic_smp_call_function_single_interrupt+0xd8/0xfc
 [] xen_call_function_single_interrupt+0x13/0x28
 [] handle_IRQ_event+0x66/0x120
 [] handle_percpu_irq+0x41/0x6e
 [] __xen_evtchn_do_upcall+0x1ab/0x27d
 [] xen_evtchn_do_upcall+0x33/0x46
 [] xen_do_hyper visor_callback+0x1e/0x30
 
 [] ? _spin_unlock_irqrestore+0x15/0x17
 [] ? xen_restore_fl_direct_end+0x0/0x1
 [] ? flush_old_exec+0x3ac/0x500
 [] ? load_elf_binary+0x0/0x17ef
 [] ? load_elf_binary+0x0/0x17ef
 [] ? load_elf_binary+0x398/0x17ef
 [] ? need_resched+0x23/0x2d
 [] ? process_measurement+0xc0/0xd7
 [] ? load_elf_binary+0x0/0x17ef
 [] ? search_binary_handler+0xc8/0x255
 [] ? do_execve+0x1c3/0x29e
 [] ? sys_execve+0x43/0x5d
 [] ? __call_usermodehelper+0x0/0x6f
 [] ? kernel_execve+0x68/0xd0
 [] ? __call_usermodehelper+0x0/0x6f
 [] ? xen_restore_fl_direct_end+0x0/0x1
 [] ? ____call_usermodehelper+0x113/0x11e
 [] ? child_rip+0xa/0x20
 [] ? __call_usermodehelper+0x0/0x6f
 [] ? int_ret_from_sys_call+0x7/0x1b
 [] ? retint_restore_args+0x5/0x6
 [] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP  [] leave_mm+0x15/0x46
 RSP 
---[ end trace ce9cee6832a9c503 ]---

Tested-by: Maoxiaoyun
Signed-off-by: Kevin Tian 
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area

2011-06-23T22:28:37+00:00

commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream.

The v6 and v7 implementations of flush_kern_dcache_area do not align
the passed MVA to the size of a cacheline in the data cache. If a
misaligned address is used, only a subset of the requested area will
be flushed. This has been observed to cause failures in SMP boot where
the secondary_data initialised by the primary CPU is not cacheline
aligned, causing the secondary CPUs to read incorrect values for their
pgd and stack pointers.

This patch ensures that the base address is cacheline aligned before
flushing the d-cache.

Acked-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

x86, amd: Use _safe() msr access for GartTlbWlk disable code

2011-06-23T22:28:35+00:00

commit d47cc0db8fd6011de2248df505fc34990b7451bf upstream.

The workaround for Bugzilla:

	https://bugzilla.kernel.org/show_bug.cgi?id=33012

introduced a read and a write to the MC4 mask msr.

Unfortunatly this MSR is not emulated by the KVM hypervisor
so that the kernel will get a #GP and crashes when applying
this workaround when running inside KVM.

This issue was reported as:

	https://bugzilla.kernel.org/show_bug.cgi?id=35132

and is fixed with this patch. The change just let the kernel
ignore any #GP it gets while accessing this MSR by using the
_safe msr access methods.

Reported-by: Török Edwin 
Signed-off-by: Joerg Roedel 
Cc: Rafael J. Wysocki 
Cc: Maciej Rutecki 
Cc: Avi Kivity 
Cc: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman