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

signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer

2013-03-27T02:41:25+00:00

flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined.  Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.

Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.

Signed-off-by: Ben Hutchings 
Cc: Al Viro

x86-64: Fix the failure case in copy_user_handle_tail()

2013-03-27T02:41:17+00:00

commit 66db3feb486c01349f767b98ebb10b0c3d2d021b upstream.

The increment of "to" in copy_user_handle_tail() will have incremented
before a failure has been noted.  This causes us to skip a byte in the
failure case.

Only do the increment when assured there is no failure.

Signed-off-by: CQ Tang 
Link: http://lkml.kernel.org/r/20130318150221.8439.993.stgit@phlsvslse11.ph.intel.com
Signed-off-by: Mike Marciniszyn 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Ben Hutchings

powerpc: Fix cputable entry for 970MP rev 1.0

2013-03-27T02:41:02+00:00

commit d63ac5f6cf31c8a83170a9509b350c1489a7262b upstream.

Commit 44ae3ab3358e962039c36ad4ae461ae9fb29596c forgot to update
the entry for the 970MP rev 1.0 processor when moving some CPU
features bits to the MMU feature bit mask. This breaks booting
on some rare G5 models using that chip revision.

Reported-by: Phileas Fogg 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings

s390/mm: fix flush_tlb_kernel_range()

2013-03-27T02:41:00+00:00

commit f6a70a07079518280022286a1dceb797d12e1edf upstream.

Our flush_tlb_kernel_range() implementation calls __tlb_flush_mm() with
&init_mm as argument. __tlb_flush_mm() however will only flush tlbs
for the passed in mm if its mm_cpumask is not empty.

For the init_mm however its mm_cpumask has never any bits set. Which in
turn means that our flush_tlb_kernel_range() implementation doesn't
work at all.

This can be easily verified with a vmalloc/vfree loop which allocates
a page, writes to it and then frees the page again. A crash will follow
almost instantly.

To fix this remove the cpumask_empty() check in __tlb_flush_mm() since
there shouldn't be too many mms with a zero mm_cpumask, besides the
init_mm of course.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Ben Hutchings

perf,x86: fix wrmsr_on_cpu() warning on suspend/resume

2013-03-27T02:40:55+00:00

commit 2a6e06b2aed6995af401dcd4feb5e79a0c7ea554 upstream.

Commit 1d9d8639c063 ("perf,x86: fix kernel crash with PEBS/BTS after
suspend/resume") fixed a crash when doing PEBS performance profiling
after resuming, but in using init_debug_store_on_cpu() to restore the
DS_AREA mtrr it also resulted in a new WARN_ON() triggering.

init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU
cross-calls to do the MSR update.  Which is not really valid at the
early resume stage, and the warning is quite reasonable.  Now, it all
happens to _work_, for the simple reason that smp_call_function_single()
ends up just doing the call directly on the CPU when the CPU number
matches, but we really should just do the wrmsr() directly instead.

This duplicates the wrmsr() logic, but hopefully we can just remove the
wrmsr_on_cpu() version eventually.

Reported-and-tested-by: Parag Warudkar 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

perf,x86: fix kernel crash with PEBS/BTS after suspend/resume

2013-03-27T02:40:54+00:00

commit 1d9d8639c063caf6efc2447f5f26aa637f844ff6 upstream.

This patch fixes a kernel crash when using precise sampling (PEBS)
after a suspend/resume. Turns out the CPU notifier code is not invoked
on CPU0 (BP). Therefore, the DS_AREA (used by PEBS) is not restored properly
by the kernel and keeps it power-on/resume value of 0 causing any PEBS
measurement to crash when running on CPU0.

The workaround is to add a hook in the actual resume code to restore
the DS Area MSR value. It is invoked for all CPUS. So for all but CPU0,
the DS_AREA will be restored twice but this is harmless.

Reported-by: Linus Torvalds 
Signed-off-by: Stephane Eranian 
Signed-off-by: Linus Torvalds 
Signed-off-by: Ben Hutchings

ARM: 7663/1: perf: fix ARMv7 EVTYPE_MASK to include NSH bit

2013-03-20T15:03:21+00:00

commit f2fe09b055e2549de41fb107b34c60bac4a1b0cf upstream.

Masked out PMXEVTYPER.NSH means that we can't enable profiling at PL2,
regardless of the settings in the HDCR.

This patch fixes the broken mask.

Reported-by: Christoffer Dall 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

xen/pci: We don't do multiple MSI's.

2013-03-20T15:03:20+00:00

commit 884ac2978a295b7df3c4a686d3bff6932bbbb460 upstream.

There is no hypercall to setup multiple MSI per PCI device.
As such with these two new commits:
-  08261d87f7d1b6253ab3223756625a5c74532293
   PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
- 5ca72c4f7c412c2002363218901eba5516c476b1
   AHCI: Support multiple MSIs

we would call the PHYSDEVOP_map_pirq 'nvec' times with the same
contents of the PCI device. Sander discovered that we would get
the same PIRQ value 'nvec' times and return said values to the
caller. That of course meant that the device was configured only
with one MSI and AHCI would fail with:

ahci 0000:00:11.0: version 3.0
xen: registering gsi 19 triggering 0 polarity 1
xen: --> pirq=19 -> irq=19 (gsi=19)
(XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1)
ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part
ahci: probe of 0000:00:11.0 failed with error -22

That is b/c in ahci_host_activate the second call to
devm_request_threaded_irq  would return -EINVAL as we passed in
(on the second run) an IRQ that was never initialized.

Reported-and-Tested-by: Sander Eikelenboom 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

ARM: fix scheduling while atomic warning in alignment handling code

2013-03-20T15:03:17+00:00

commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream.

Paolo Pisati reports that IPv6 triggers this warning:

BUG: scheduling while atomic: swapper/0/0/0x40000100
Modules linked in:
[] (unwind_backtrace+0x0/0xf0) from [] (__schedule_bug+0x48/0x5c)
[] (__schedule_bug+0x48/0x5c) from [] (__schedule+0x700/0x740)
[] (__schedule+0x700/0x740) from [] (__cond_resched+0x24/0x34)
[] (__cond_resched+0x24/0x34) from [] (_cond_resched+0x3c/0x44)
[] (_cond_resched+0x3c/0x44) from [] (do_alignment+0x178/0x78c)
[] (do_alignment+0x178/0x78c) from [] (do_DataAbort+0x34/0x98)
[] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x40/0x60)
Exception stack(0xc0763d70 to 0xc0763db8)
3d60:                                     e97e805e e97e806e 2c000000 11000000
3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c
3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff
[] (__dabt_svc+0x40/0x60) from [] (__csum_ipv6_magic+0x8/0xc8)

Fix this by using probe_kernel_address() stead of __get_user().

Reported-by: Paolo Pisati 
Tested-by: Paolo Pisati 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings

ARM: VFP: fix emulation of second VFP instruction

2013-03-20T15:03:17+00:00

commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö 
Tested-by: Martin Storsjö 
Signed-off-by: Russell King 
Signed-off-by: Ben Hutchings