linux-stable.git/arch/powerpc, branch v3.2.72

powerpc/MSI: Fix race condition in tearing down MSI interrupts

2015-10-13T02:46:08+00:00

commit e297c939b745e420ef0b9dc989cb87bda617b399 upstream.

This fixes a race which can result in the same virtual IRQ number
being assigned to two different MSI interrupts.  The most visible
consequence of that is usually a warning and stack trace from the
sysfs code about an attempt to create a duplicate entry in sysfs.

The race happens when one CPU (say CPU 0) is disposing of an MSI
while another CPU (say CPU 1) is setting up an MSI.  CPU 0 calls
(for example) pnv_teardown_msi_irqs(), which calls
msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
hardware IRQ number) is no longer in use.  Then, before CPU 0 gets
to calling irq_dispose_mapping() to free up the virtal IRQ number,
CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
MSI, and gets the same hardware IRQ number that CPU 0 just freed.
CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
which sees that there is currently a mapping for that hardware IRQ
number and returns the corresponding virtual IRQ number (which is
the same virtual IRQ number that CPU 0 was using).  CPU 0 then
calls irq_dispose_mapping() and frees that virtual IRQ number.
Now, if another CPU comes along and calls irq_create_mapping(), it
is likely to get the virtual IRQ number that was just freed,
resulting in the same virtual IRQ number apparently being used for
two different hardware interrupts.

To fix this race, we just move the call to msi_bitmap_free_hwirqs()
to after the call to irq_dispose_mapping().  Since virq_to_hw()
doesn't work for the virtual IRQ number after irq_dispose_mapping()
has been called, we need to call it before irq_dispose_mapping() and
remember the result for the msi_bitmap_free_hwirqs() call.

The pattern of calling msi_bitmap_free_hwirqs() before
irq_dispose_mapping() appears in 5 places under arch/powerpc, and
appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC
U3/U4 MSI backend") from 2007.

Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend")
Reported-by: Alexey Kardashevskiy 
Signed-off-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
[bwh: Backported to 3.2:
 - powernv uses a private functions instead of msi_bitmap_free_hwirqs()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

powerpc+sparc64/mm: Remove hack in mmap randomize layout

2015-08-06T23:32:18+00:00

commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb upstream.

Since commit 8a0a9bd4db63bc45e301, this comment in mmap_rnd() does not
hold true as the value returned by get_random_int() will in fact be

different every single call. Remove the comment and simplify the code
back to its original desired form.

This reverts commit a5adc91a4b44b5d1 which is no longer necessary and
also fixes the sparc code that copied this same adjustment.

Signed-off-by: Dan McGee 
Acked-by: David S. Miller 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings 
Cc: Moritz Mühlenhoff

powerpc: Don't skip ePAPR spin-table CPUs

2015-08-06T23:32:16+00:00

commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream.

Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup
CPUs with bad status" broke ePAPR SMP booting.  ePAPR says that CPUs
that aren't presently running shall have status of disabled, with
enable-method being used to determine whether the CPU can be enabled.

Fix by checking for spin-table, which is currently the only supported
enable-method.

Signed-off-by: Scott Wood 
Cc: Michael Neuling 
Cc: Emil Medve 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Ben Hutchings 
Cc: Jonathan Toppins

powerpc: Make logical to real cpu mapping code endian safe

2015-08-06T23:32:16+00:00

commit ac13282dff13cd0f4da0f0ccb134bc29bfa10255 upstream.

Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt 
[jt: fixed up context due to commit 59a53afe70fd530040bdc69581f03d880157f15a
     already being backported.]
Signed-off-by: Jonathan Toppins 
Reviewed-by: Andy Gospodarek 
Acked-by: Curt Brune 
Acked-by: Roopa Prabhu 
Signed-off-by: Ben Hutchings

powerpc: Align TOC to 256 bytes

2015-08-06T23:32:11+00:00

commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.

Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.

If they are bad, we die a few hundred instructions into boot.

Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Ben Hutchings

powerpc/pseries: Correct cpu affinity for dlpar added cpus

2015-08-06T23:32:09+00:00

commit f32393c943e297b8ae180c8f83d81a156c7d0412 upstream.

The incorrect ordering of operations during cpu dlpar add results in invalid
affinity for the cpu being added. The ibm,associativity property in the
device tree is populated with all zeroes for the added cpu which results in
invalid affinity mappings and all cpus appear to belong to node 0.

This occurs because rtas configure-connector is called prior to making the
rtas set-indicator calls. Phyp does not assign affinity information
for a cpu until the rtas set-indicator calls are made to set the isolation
and allocation state.

Correct the order of operations to make the rtas set-indicator
calls (done in dlpar_acquire_drc) before calling rtas configure-connector.

Fixes: 1a8061c46c46 ("powerpc/pseries: Add kernel based CPU DLPAR handling")

Signed-off-by: Nathan Fontenot 
Signed-off-by: Michael Ellerman 
[bwh: Backported to 3.2:
 - Adjust context
 - Keep using goto instead of directly returning]
Signed-off-by: Ben Hutchings

powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH

2015-08-06T23:32:04+00:00

commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream.

We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH
(currently 127), but we forgot to do the same for 64bit backtraces.

Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings

powerpc: Fix missing L2 cache size in /sys/devices/system/cpu

2015-08-06T23:32:03+00:00

commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.

This problem appears to have been introduced in 2.6.29 by commit
93197a36a9c1 "Rewrite sysfs processor cache info code".

This caused lscpu to error out on at least e500v2 devices, eg:

  error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory

Some embedded powerpc systems use cache-size in DTS for the unified L2
cache size, not d-cache-size, so we need to allow for both DTS names.
Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle
this.

Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code")
Signed-off-by: Dave Olson 
Signed-off-by: Michael Ellerman 
[bwh: Backported to 3.2:
 - Adjust context
 - Preserve __cpuinit attribute on cache_do_one_devnode_unified()]
Signed-off-by: Ben Hutchings

axonram: Fix bug in direct_access

2015-05-09T22:16:12+00:00

commit 91117a20245b59f70b563523edbf998a62fc6383 upstream.

The 'pfn' returned by axonram was completely bogus, and has been since
2008.

Signed-off-by: Matthew Wilcox 
Reviewed-by: Jan Kara 
Reviewed-by: Mathieu Desnoyers 
Signed-off-by: Jens Axboe 
Signed-off-by: Ben Hutchings

vm: add VM_FAULT_SIGSEGV handling support

2015-02-20T00:49:40+00:00

commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.

The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
"you should SIGSEGV" error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.

That results in lots of duplication - all the architecture fault
handlers end up doing very similar "look up vma, check permissions, do
retries etc" - but it generally works.  However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.

In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV.  And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.

However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 ("mm: propagate error
from stack expansion even for guard page"), that now exposed the
existing VM_FAULT_SIGBUS result to user space.  And user space really
expected SIGSEGV, not SIGBUS.

To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it.  They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.

This is the mindless minimal patch to do this.  A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.

Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
"newer" things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.

Reported-and-tested-by: Takashi Iwai 
Tested-by: Jan Engelhardt 
Acked-by: Heiko Carstens  # "s390 still compiles and boots"
Cc: linux-arch@vger.kernel.org
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.2:
 - Adjust filenames, context
 - Drop arc, metag, nios2 and lustre changes
 - For sh, patch both 32-bit and 64-bit implementations to use goto bad_area
 - For s390, pass int_code and trans_exc_code as arguments to do_no_context()
   and do_sigsegv()]
Signed-off-by: Ben Hutchings