linux-toradex.git/arch/parisc, branch v3.4.78

parisc: Do not crash 64bit SMP kernels on machines with >= 4GB RAM

2013-11-13T03:01:49+00:00

commit 54e181e073fc1415e41917d725ebdbd7de956455 upstream.

Since the beginning of the parisc-linux port, sometimes 64bit SMP kernels were
not able to bring up other CPUs than the monarch CPU and instead crashed the
kernel.  The reason was unclear, esp. since it involved various machines (e.g.
J5600, J6750 and SuperDome). Testing showed, that those crashes didn't happened
when less than 4GB were installed, or if a 32bit Linux kernel was booted.

In the end, the fix for those SMP problems is trivial:
During the early phase of the initialization of the CPUs, including the monarch
CPU, the PDC_PSW firmware function to enable WIDE (=64bit) mode is called.
It's documented that this firmware function may clobber various registers, and
one one of those possibly clobbered registers is %cr30 which holds the task
thread info pointer.

Now, if %cr30 would always have been clobbered, then this bug would have been
detected much earlier. But lots of testing finally showed, that - at least for
%cr30 - on some machines only the upper 32bits of the 64bit register suddenly
turned zero after the firmware call.

So, after finding the root cause, the explanation for the various crashes
became clear:
- On 32bit SMP Linux kernels all upper 32bit were zero, so we didn't faced this
  problem.
- Monarch CPUs in 64bit mode always booted sucessfully, because the inital task
  thread info pointer was below 4GB.
- Secondary CPUs booted sucessfully on machines with less than 4GB RAM because
  the upper 32bit were zero anyay.
- Secondary CPus failed to boot if we had more than 4GB RAM and the task thread
  info pointer was located above the 4GB boundary.

Finally, the patch to fix this problem is trivial by saving the %cr30 register
before the firmware call and restoring it afterwards.

Signed-off-by: Helge Deller 
Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: fix interruption handler to respect pagefault_disable()

2013-10-22T08:02:25+00:00

commit 59b33f148cc08fb33cbe823fca1e34f7f023765e upstream.

Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel.  The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
    probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
    probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
    probe_kernel_read(name, wq->name, sizeof(name) - 1);

The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.

With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0).  Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.

Signed-off-by: Helge Deller 
Signed-off-by: John David Anglin  
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

mm, show_mem: suppress page counts in non-blockable contexts

2013-10-13T22:42:49+00:00

commit 4b59e6c4730978679b414a8da61514a2518da512 upstream.

On large systems with a lot of memory, walking all RAM to determine page
types may take a half second or even more.

In non-blockable contexts, the page allocator will emit a page allocation
failure warning unless __GFP_NOWARN is specified.  In such contexts, irqs
are typically disabled and such a lengthy delay may even result in NMI
watchdog timeouts.

To fix this, suppress the page walk in such contexts when printing the
page allocation failure warning.

Signed-off-by: David Rientjes 
Cc: Mel Gorman 
Acked-by: Michal Hocko 
Cc: Dave Hansen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Xishi Qiu 
Signed-off-by: Greg Kroah-Hartman

Purge existing TLB entries in set_pte_at and ptep_set_wrprotect

2013-02-28T14:59:05+00:00

commit 7139bc1579901b53db7e898789e916ee2fb52d78 upstream.

This patch goes a long way toward fixing the minifail bug, and
it  significantly improves the stability of SMP machines such as
the rp3440.  When write  protecting a page for COW, we need to
purge the existing translation.  Otherwise, the COW break
doesn't occur as expected because the TLB may still have a stale entry
which allows writes.

[jejb: fix up checkpatch errors]
Signed-off-by: John David Anglin 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

PARISC: fix user-triggerable panic on parisc

2012-12-03T19:47:05+00:00

commit 441a179dafc0f99fc8b3a8268eef66958621082e upstream.

int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset,
                                    unsigned int sigsetsize)
{
        sigset_t old_set, new_set;
        int ret;

        if (set && get_sigset32(set, &new_set, sigsetsize))

...
static int
get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz)
{
        compat_sigset_t s;
        int r;

        if (sz != sizeof *set) panic("put_sigset32()");

In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process
will promptly panic the box.

Signed-off-by: Al Viro 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

PARISC: fix virtual aliasing issue in get_shared_area()

2012-12-03T19:47:05+00:00

commit 949a05d03490e39e773e8652ccab9157e6f595b4 upstream.

On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
> Looking at the arch/parisc/kernel/sys_parisc.c implementation of
> get_shared_area(), I do have a concern though. The function basically
> ignores the pgoff argument, so that if one creates a shared mapping of
> pages 0-N of a file, and then a separate shared mapping of pages 1-N
> of that same file, both will have the same cache offset for their
> starting address.
>
> This looks like this would create obvious aliasing issues. Am I
> misreading this ? I can't understand how this could work good enough
> to be undetected, so there must be something I'm missing here ???

This turns out to be correct and we need to pay attention to the pgoff as
well as the address when creating the virtual address for the area.
Fortunately, the bug is rarely triggered as most applications which use pgoff
tend to use large values (git being the primary one, and it uses pgoff in
multiples of 16MB) which are larger than our cache coherency modulus, so the
problem isn't often seen in practise.

Reported-by: Michel Lespinasse 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

parisc: Add missing RCU idle APIs on idle loop

2012-10-12T20:38:53+00:00

commit fbe752188d5589e7fcbb8e79824e560f77dccc92 upstream.

In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.

So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.

This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.

Add this missing pair of calls in the parisc's idle loop.

Reported-by: Paul E. McKenney 
Signed-off-by: Frederic Weisbecker 
Cc: James E.J. Bottomley 
Cc: Helge Deller 
Cc: Parisc 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
Signed-off-by: Greg Kroah-Hartman

PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

2012-09-14T17:00:33+00:00

commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream.

The following build error occured during a parisc build with
swap-over-NFS patches applied.

net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Reported-by: Fengguang Wu 
Signed-off-by: Mel Gorman 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

PARISC: fix TLB fault path on PA2.0 narrow systems

2012-06-09T15:36:07+00:00

commit 2f649c1f6f0fef445ce79a19b79e5ce8fe9d7f19 upstream.

commit 5e185581d7c46ddd33cd9c01106d1fc86efb9376
Author: James Bottomley 

    [PARISC] fix PA1.1 oops on boot

Didn't quite fix the crash on boot.  It moved it from PA1.1 processors to
PA2.0 narrow kernels.  The final fix is to make sure the [id]tlb_miss_20 paths
also work.  Even on narrow systems, these paths require using the wide
instructions becuase the tlb insertion format is wide.  Fix this by
conditioning the dep[wd],z on whether we're being called from _11 or _20[w]
paths.

Tested-by: Helge Deller 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

PARISC: fix boot failure on 32-bit systems caused by branch stubs placed before .text

2012-06-09T15:36:07+00:00

commit ed5fb2471b7060767957fb964eb1aaec71533ab1 upstream.

In certain configurations, the resulting kernel becomes too large to boot
because the linker places the long branch stubs for the merged .text section
at the very start of the image.  As a result, the initial transfer of control
jumps to an unexpected location.  Fix this by placing the head text in a
separate section so the stubs for .text are not at the start of the image.

Signed-off-by: John David Anglin 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman