linux.git/arch/sparc, branch v3.10.76

vm: add VM_FAULT_SIGSEGV handling support

2015-04-29T08:34:00+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 
[shengyong: Backport to 3.10
 - adjust context
 - ignore modification for arch nios2, because 3.10 does not support it
 - ignore modification for driver lustre, because 3.10 does not support it
 - ignore VM_FAULT_FALLBACK in VM_FAULT_ERROR, becase 3.10 does not support
   this flag
 - add SIGSEGV handling to powerpc/cell spu_fault.c, because 3.10 does not
   separate it to copro_fault.c
 - add SIGSEGV handling in mm/memory.c, because 3.10 does not separate it
   to gup.c
]
Signed-off-by: Sheng Yong 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix several bugs in memmove().

2015-03-26T14:00:55+00:00

[ Upstream commit 2077cef4d5c29cf886192ec32066f783d6a80db8 ]

Firstly, handle zero length calls properly.  Believe it or not there
are a few of these happening during early boot.

Next, we can't just drop to a memcpy() call in the forward copy case
where dst <= src.  The reason is that the cache initializing stores
used in the Niagara memcpy() implementations can end up clearing out
cache lines before we've sourced their original contents completely.

For example, considering NG4memcpy, the main unrolled loop begins like
this:

     load   src + 0x00
     load   src + 0x08
     load   src + 0x10
     load   src + 0x18
     load   src + 0x20
     store  dst + 0x00

Assume dst is 64 byte aligned and let's say that dst is src - 8 for
this memcpy() call.  That store at the end there is the one to the
first line in the cache line, thus clearing the whole line, which thus
clobbers "src + 0x28" before it even gets loaded.

To avoid this, just fall through to a simple copy only mildly
optimized for the case where src and dst are 8 byte aligned and the
length is a multiple of 8 as well.  We could get fancy and call
GENmemcpy() but this is good enough for how this thing is actually
used.

Reported-by: David Ahern 
Reported-by: Bob Picco 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Touch NMI watchdog when walking cpus and calling printk

2015-03-26T14:00:55+00:00

[ Upstream commit 31aaa98c248da766ece922bbbe8cc78cfd0bc920 ]

With the increase in number of CPUs calls to functions that dump
output to console (e.g., arch_trigger_all_cpu_backtrace) can take
a long time to complete. If IRQs are disabled eventually the NMI
watchdog kicks in and creates more havoc. Avoid by telling the NMI
watchdog everything is ok.

Signed-off-by: David Ahern 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: perf: Make counting mode actually work

2015-03-26T14:00:55+00:00

[ Upstream commit d51291cb8f32bfae6b331e1838651f3ddefa73a5 ]

Currently perf-stat (aka, counting mode) does not work:

$ perf stat ls
...
 Performance counter stats for 'ls':

          1.585665      task-clock (msec)         #    0.580 CPUs utilized
                24      context-switches          #    0.015 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                86      page-faults               #    0.054 M/sec
         cycles
         stalled-cycles-frontend
         stalled-cycles-backend
         instructions
         branches
         branch-misses

       0.002735100 seconds time elapsed

The reason is that state is never reset (stays with PERF_HES_UPTODATE set).
Add a call to sparc_pmu_enable_event during the added_event handling.
Clean up the encoding since pmu_start calls sparc_pmu_enable_event which
does the same. Passing PERF_EF_RELOAD to sparc_pmu_start means the call
to sparc_perf_event_set_period can be removed as well.

With this patch:

$ perf stat ls
...
 Performance counter stats for 'ls':

          1.552890      task-clock (msec)         #    0.552 CPUs utilized
                24      context-switches          #    0.015 M/sec
                 0      cpu-migrations            #    0.000 K/sec
                86      page-faults               #    0.055 M/sec
         5,748,997      cycles                    #    3.702 GHz
         stalled-cycles-frontend:HG
         stalled-cycles-backend:HG
         1,684,362      instructions:HG           #    0.29  insns per cycle
           295,133      branches:HG               #  190.054 M/sec
            28,007      branch-misses:HG          #    9.49% of all branches

       0.002815665 seconds time elapsed

Signed-off-by: David Ahern 
Acked-by: Bob Picco 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: perf: Remove redundant perf_pmu_{en|dis}able calls

2015-03-26T14:00:54+00:00

[ Upstream commit 5b0d4b5514bbcce69b516d0742f2cfc84ebd6db3 ]

perf_pmu_disable is called by core perf code before pmu->del and the
enable function is called by core perf code afterwards. No need to
call again within sparc_pmu_del.

Ditto for pmu->add and sparc_pmu_add.

Signed-off-by: David Ahern 
Acked-by: Bob Picco 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: semtimedop() unreachable due to comparison error

2015-03-26T14:00:54+00:00

[ Upstream commit 53eb2516972b8c4628651dfcb926cb9ef8b2864a ]

A bug was reported that the semtimedop() system call was always
failing eith ENOSYS.

Since SEMCTL is defined as 3, and SEMTIMEDOP is defined as 4,
the comparison "call <= SEMCTL" will always prevent SEMTIMEDOP
from getting through to the semaphore ops switch statement.

This is corrected by changing the comparison to "call <= SEMTIMEDOP".

Orabug: 20633375

Signed-off-by: Rob Gardner 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc32: destroy_context() and switch_mm() needs to disable interrupts.

2015-03-26T14:00:54+00:00

[ Upstream commit 66d0f7ec9f1038452178b1993fc07fd96d30fd38 ]

Load balancing can be triggered in the critical sections protected by
srmmu_context_spinlock in destroy_context() and switch_mm() and can hang
the cpu waiting for the rq lock of another cpu that in turn has called
switch_mm hangning on srmmu_context_spinlock leading to deadlock.

So, disable interrupt while taking srmmu_context_spinlock in
destroy_context() and switch_mm() so we don't deadlock.

See also commit 77b838fa1ef0 ("[SPARC64]: destroy_context() needs to disable
interrupts.")

Signed-off-by: Andreas Larsson 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

crypto: prefix module autoloading with "crypto-"

2015-01-30T01:40:57+00:00

commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.

This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:

https://lkml.org/lkml/2013/3/4/70

Signed-off-by: Kees Cook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix constraints on swab helpers.

2014-12-06T23:05:46+00:00

[ Upstream commit 5a2b59d3993e8ca4f7788a48a23e5cb303f26954 ]

We are reading the memory location, so we have to have a memory
constraint in there purely for the sake of showing the data flow
to the compiler.

Reported-by: Martin K. Petersen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

arch: mm: pass userspace fault flag to generic fault handler

2014-11-21T17:22:56+00:00

commit 759496ba6407c6994d6a5ce3a5e74937d7816208 upstream.

Unlike global OOM handling, memory cgroup code will invoke the OOM killer
in any OOM situation because it has no way of telling faults occuring in
kernel context - which could be handled more gracefully - from
user-triggered faults.

Pass a flag that identifies faults originating in user space from the
architecture-specific fault handlers to generic code so that memcg OOM
handling can be improved.

Signed-off-by: Johannes Weiner 
Reviewed-by: Michal Hocko 
Cc: David Rientjes 
Cc: KAMEZAWA Hiroyuki 
Cc: azurIt 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Cong Wang 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman