linux-toradex.git/arch, branch v3.2.31

x86/alternatives: Fix p6 nops on non-modular kernels

2012-10-10T02:31:15+00:00

commit cb09cad44f07044d9810f18f6f9a6a6f3771f979 upstream.

Probably a leftover from the early days of self-patching, p6nops
are marked __initconst_or_module, which causes them to be
discarded in a non-modular kernel.  If something later triggers
patching, it will overwrite kernel code with garbage.

Reported-by: Tomas Racek 
Signed-off-by: Avi Kivity 
Cc: Michael Tokarev 
Cc: Borislav Petkov 
Cc: Marcelo Tosatti 
Cc: qemu-devel@nongnu.org
Cc: Anthony Liguori 
Cc: H. Peter Anvin 
Cc: Alan Cox 
Cc: Alan Cox 
Link: http://lkml.kernel.org/r/5034AE84.90708@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

xen/boot: Disable NUMA for PV guests.

2012-10-10T02:31:04+00:00

commit 8d54db795dfb1049d45dc34f0dddbc5347ec5642 upstream.

The hypervisor is in charge of allocating the proper "NUMA" memory
and dealing with the CPU scheduler to keep them bound to the proper
NUMA node. The PV guests (and PVHVM) have no inkling of where they
run and do not need to know that right now. In the future we will
need to inject NUMA configuration data (if a guest spans two or more
NUMA nodes) so that the kernel can make the right choices. But those
patches are not yet present.

In the meantime, disable the NUMA capability in the PV guest, which
also fixes a bootup issue. Andre says:

"we see Dom0 crashes due to the kernel detecting the NUMA topology not
by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA).

This will detect the actual NUMA config of the physical machine, but
will crash about the mismatch with Dom0's virtual memory. Variation of
the theme: Dom0 sees what it's not supposed to see.

This happens with the said config option enabled and on a machine where
this scanning is still enabled (K8 and Fam10h, not Bulldozer class)

We have this dump then:
NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
Scanning NUMA topology in Northbridge 24
Number of physical nodes 4
Node 0 MemBase 0000000000000000 Limit 0000000040000000
Node 1 MemBase 0000000040000000 Limit 0000000138000000
Node 2 MemBase 0000000138000000 Limit 00000001f8000000
Node 3 MemBase 00000001f8000000 Limit 0000000238000000
Initmem setup node 0 0000000000000000-0000000040000000
  NODE_DATA [000000003ffd9000 - 000000003fffffff]
Initmem setup node 1 0000000040000000-0000000138000000
  NODE_DATA [0000000137fd9000 - 0000000137ffffff]
Initmem setup node 2 0000000138000000-00000001f8000000
  NODE_DATA [00000001f095e000 - 00000001f0984fff]
Initmem setup node 3 00000001f8000000-0000000238000000
Cannot find 159744 bytes in node 3
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __alloc_bootmem_node+0x43/0x96
Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar
RIP: e030:[]  [] __alloc_bootmem_node+0x43/0x96
.. snip..
  [] sparse_early_usemaps_alloc_node+0x64/0x178
  [] sparse_init+0xe4/0x25a
  [] paging_init+0x13/0x22
  [] setup_arch+0x9c6/0xa9b
  [] ? printk+0x3c/0x3e
  [] start_kernel+0xe5/0x468
  [] x86_64_start_reservations+0xba/0xc1
  [] ? xen_setup_runstate_info+0x2c/0x36
  [] xen_start_kernel+0x565/0x56c
"

so we just disable NUMA scanning by setting numa_off=1.

Reported-and-Tested-by: Andre Przywara 
Acked-by: Andre Przywara 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen/boot: Disable BIOS SMP MP table search.

2012-10-10T02:30:59+00:00

commit bd49940a35ec7d488ae63bd625639893b3385b97 upstream.

As the initial domain we are able to search/map certain regions
of memory to harvest configuration data. For all low-level we
use ACPI tables - for interrupts we use exclusively ACPI _PRT
(so DSDT) and MADT for INT_SRC_OVR.

The SMP MP table is not used at all. As a matter of fact we do
not even support machines that only have SMP MP but no ACPI tables.

Lets follow how Moorestown does it and just disable searching
for BIOS SMP tables.

This also fixes an issue on HP Proliant BL680c G5 and DL380 G6:

9f->100 for 1:1 PTE
Freeing 9f-100 pfn range: 97 pages freed
1-1 mapping on 9f->100
.. snip..
e820: BIOS-provided physical RAM map:
Xen: [mem 0x0000000000000000-0x000000000009efff] usable
Xen: [mem 0x000000000009f400-0x00000000000fffff] reserved
Xen: [mem 0x0000000000100000-0x00000000cfd1dfff] usable
.. snip..
Scan for SMP in [mem 0x00000000-0x000003ff]
Scan for SMP in [mem 0x0009fc00-0x0009ffff]
Scan for SMP in [mem 0x000f0000-0x000fffff]
found SMP MP-table at [mem 0x000f4fa0-0x000f4faf] mapped at [ffff8800000f4fa0]
(XEN) mm.c:908:d0 Error getting mfn 100 (pfn 5555555555555555) from L1 entry 0000000000100461 for l1e_owner=0, pg_owner=0
(XEN) mm.c:4995:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [] xen_set_pte_init+0x66/0x71
. snip..
Pid: 0, comm: swapper Not tainted 3.6.0-rc6upstream-00188-gb6fb969-dirty #2 HP ProLiant BL680c G5
.. snip..
Call Trace:
 [] __early_ioremap+0x18a/0x248
 [] ? printk+0x48/0x4a
 [] early_ioremap+0x13/0x15
 [] get_mpc_size+0x2f/0x67
 [] smp_scan_config+0x10c/0x136
 [] default_find_smp_config+0x36/0x5a
 [] setup_arch+0x5b3/0xb5b
 [] ? printk+0x48/0x4a
 [] start_kernel+0x90/0x390
 [] x86_64_start_reservations+0x131/0x136
 [] xen_start_kernel+0x65f/0x661
(XEN) Domain 0 crashed: 'noreboot' set - not rebooting.

which is that ioremap would end up mapping 0xff using _PAGE_IOMAP
(which is what early_ioremap sticks as a flag) - which meant
we would get MFN 0xFF (pte ff461, which is OK), and then it would
also map 0x100 (b/c ioremap tries to get page aligned request, and
it was trying to map 0xf4fa0 + PAGE_SIZE - so it mapped the next page)
as _PAGE_IOMAP. Since 0x100 is actually a RAM page, and the _PAGE_IOMAP
bypasses the P2M lookup we would happily set the PTE to 1000461.
Xen would deny the request since we do not have access to the
Machine Frame Number (MFN) of 0x100. The P2M[0x100] is for example
0x80140.

Fixes-Oracle-Bugzilla: https://bugzilla.oracle.com/bugzilla/show_bug.cgi?id=13665
Acked-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

ARM: 7532/1: decompressor: reset SCTLR.TRE for VMSA ARMv7 cores

2012-10-10T02:30:53+00:00

commit e1e5b7e4251c7538ca08c2c5545b0c2fbd8a6635 upstream.

This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
cacheable for ARMv7 cores in the decompressor, ensuring that the
memory region attributes are obtained from the C and B bits, not from
the page tables.

Cc: Nicolas Pitre 
Reviewed-by: Will Deacon 
Signed-off-by: Matthew Leach 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path

2012-09-19T14:05:18+00:00

commit 2b2040af0b64cd93e5d4df2494c4486cf604090d upstream.

get_user may fail to load from the provided __user address due to an
unhandled fault generated by the access.

In the case of the undefined instruction trap, this results in failure
to load the faulting instruction, in which case we should send SIGILL to
the task rather than continue with potentially uninitialised data.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7513/1: Make sure dtc is built before running it

2012-09-19T14:05:18+00:00

commit 70b0476a2394de4f4e32e0b67288d80ff71ca963 upstream.

'make dtbs' in a clean tree will try running the dtc before actually
building it.  Make these rules depend upon the scripts to build it.

Signed-off-by: David Brown 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type

2012-09-19T14:05:04+00:00

commit bf8801145c01ab600f8df66e8c879ac642fa5846 upstream.

From ARM debug architecture v7.1 onwards, a watchpoint exception causes
the DFAR to be updated with the faulting data address. However, DFSR.WnR
takes an UNKNOWN value and therefore cannot be used in general to
determine the access type that triggered the watchpoint.

This patch forbids watchpoints without an overflow handler from
specifying a specific access type (load/store). Those with overflow
handlers must be able to handle false positives potentially triggered by
a watchpoint of a different access type on the same address. For
SIGTRAP-based handlers (i.e. ptrace), this should have no impact.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present

2012-09-19T14:05:01+00:00

commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream.

Swap entries are encoding in ptes such that !pte_present(pte) and
pte_file(pte). The remaining bits of the descriptor are used to identify
the swapfile and offset within it to the swap entry.

When writing such a pte for a user virtual address, set_pte_at
unconditionally sets the nG bit, which (in the case of LPAE) will
corrupt the swapfile offset and lead to a BUG:

[  140.494067] swap_free: Unused swap offset entry 000763b4
[  140.509989] BUG: Bad page map in process rs:main Q:Reg  pte:0ec76800 pmd:8f92e003

This patch fixes the problem by only setting the nG bit for user
mappings that are actually present.

Reviewed-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

powerpc: Make sure IPI handlers see data written by IPI senders

2012-09-19T14:04:42+00:00

commit 9fb1b36ca1234e64a5d1cc573175303395e3354d upstream.

We have been observing hangs, both of KVM guest vcpu tasks and more
generally, where a process that is woken doesn't properly wake up and
continue to run, but instead sticks in TASK_WAKING state.  This
happens because the update of rq->wake_list in ttwu_queue_remote()
is not ordered with the update of ipi_message in
smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
scheduler_ipi() is not ordered with the reading of ipi_message in
smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
the updated rq->wake_list and therefore conclude that there is nothing
for it to do.

In order to make sure that anything done before smp_send_reschedule()
is ordered before anything done in the resulting call to scheduler_ipi(),
this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
The barrier in smp_muxed_message_pass() is a full barrier to ensure that
there is a full ordering between the smp_send_reschedule() caller and
scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
xchg_local() because xchg() includes release and acquire barriers.
Using xchg() rather than xchg_local() makes sense given that
ipi_message is not just accessed locally.

This moves the barrier between setting the message and calling the
cause_ipi() function into the individual cause_ipi implementations.
Most of them -- those that used outb, out_8 or similar -- already had
a full barrier because out_8 etc. include a sync before the MMIO
store.  This adds an explicit barrier in the two remaining cases.

These changes made no measurable difference to the speed of IPIs as
measured using a simple ping-pong latency test across two CPUs on
different cores of a POWER7 machine.

The analysis of the reason why processes were not waking up properly
is due to Milton Miller.

Reported-by: Milton Miller 
Signed-off-by: Paul Mackerras 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings

powerpc/xics: Harden xics hypervisor backend

2012-09-19T14:04:42+00:00

commit 3ce21cdfe93efffa4ffba9cf3ca2576d3d60d6dc upstream.

During kdump stress testing I sometimes see the kdump kernel panic
with:

  Interrupt 0x306 (real) is invalid, disabling it.
  Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306

Instead of panicing print the error message, dump the stack the first
time it happens and continue on. Add some more information to the
debug messages as well.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings