linux.git/arch/parisc/kernel/entry.S, branch v4.18

parisc: Define mb() and add memory barriers to assembler unlock sequences

2018-08-08T20:13:32+00:00

For years I thought all parisc machines executed loads and stores in
order. However, Jeff Law recently indicated on gcc-patches that this is
not correct. There are various degrees of out-of-order execution all the
way back to the PA7xxx processor series (hit-under-miss). The PA8xxx
series has full out-of-order execution for both integer operations, and
loads and stores.

This is described in the following article:
http://web.archive.org/web/20040214092531/http://www.cpus.hp.com/technical_references/advperf.shtml

For this reason, we need to define mb() and to insert a memory barrier
before the store unlocking spinlocks. This ensures that all memory
accesses are complete prior to unlocking. The ldcw instruction performs
the same function on entry.

Signed-off-by: John David Anglin 
Cc: stable@vger.kernel.org # 4.0+
Signed-off-by: Helge Deller

parisc: Fix alignment of pa_tlb_lock in assembly on 32-bit SMP kernel

2018-01-02T21:21:54+00:00

Qemu for PARISC reported on a 32bit SMP parisc kernel strange failures
about "Not-handled unaligned insn 0x0e8011d6 and 0x0c2011c9."

Those opcodes evaluate to the ldcw() assembly instruction which requires
(on 32bit) an alignment of 16 bytes to ensure atomicity.

As it turns out, qemu is correct and in our assembly code in entry.S and
pacache.S we don't pay attention to the required alignment.

This patch fixes the problem by aligning the lock offset in assembly
code in the same manner as we do in our C-code.

Signed-off-by: Helge Deller 
Cc:  # v4.0+

Revert "parisc: Re-enable interrupts early"

2017-12-17T20:06:25+00:00

This reverts commit 5c38602d83e584047906b41b162ababd4db4106d.

Interrupts can't be enabled early because the register saves are done on
the thread stack prior to switching to the IRQ stack.  This caused stack
overflows and the thread stack needed increasing to 32k.  Even then,
stack overflows still occasionally occurred.

Background:
Even with a 32 kB thread stack, I have seen instances where the thread
stack overflowed on the mx3210 buildd.  Detection of stack overflow only
occurs when we have an external interrupt.  When an external interrupt
occurs, we switch to the thread stack if we are not already on a kernel
stack.  Then, registers and specials are saved to the kernel stack.

The bug occurs in intr_return where interrupts are reenabled prior to
returning from the interrupt.  This was done incase we need to schedule
or deliver signals.  However, it introduces the possibility that
multiple external interrupts may occur on the thread stack and cause a
stack overflow.  These might not be detected and cause the kernel to
misbehave in random ways.

This patch changes the code back to only reenable interrupts when we are
going to schedule or deliver signals.  As a result, we generally return
from an interrupt before reenabling interrupts.  This minimizes the
growth of the thread stack.

Fixes: 5c38602d83e5 ("parisc: Re-enable interrupts early")
Signed-off-by: John David Anglin 
Cc:  # v4.10+
Signed-off-by: Helge Deller

scripts/spelling.txt: add regsiter -> register spelling mistake

2017-05-09T00:15:13+00:00

This typo is quite common.  Fix it and add it to the spelling file so
that checkpatch catches it earlier.

Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

parisc: Re-enable interrupts early

2016-12-12T21:21:50+00:00

Since kernel 3.9 we re-enable interrupts quite late due to commit c207a76bf15
("parisc: only re-enable interrupts if we need to schedule or deliver signals
when returning to userspace"). At that time the parisc kernel had no dedicated
IRQ stack, and this commit prevented kernel stack overflows.

But since commit 200c880420a ("parisc: implement irq stacks") we now have an
IRQ stack, so we may be safe now.  And when CONFIG_DEBUG_STACKOVERFLOW=y is
enabled, we can even check at runtime for overflows.

Signed-off-by: Helge Deller

parisc: Add cfi_startproc and cfi_endproc to assembly code

2016-10-05T20:54:40+00:00

Add ENTRY_CFI() and ENDPROC_CFI() macros for dwarf debug info and
convert assembly users to new macros.

Signed-off-by: Helge Deller

parisc: Use long jump to reach ftrace_return_to_handler()

2016-05-23T21:44:44+00:00

Depending on config options we will need to use a long jump to reach
ftrace_return_to_handler().  Additionally only compile the
parisc_return_to_handler code when CONFIG_FUNCTION_GRAPH_TRACER is set.

Signed-off-by: Helge Deller

parisc: Merge ftrace C-helper and assembler functions into .text.hot section

2016-05-22T19:46:21+00:00

When enabling all-branch ftrace support (CONFIG_PROFILE_ALL_BRANCHES)
the kernel gets really huge and some ftrace assembler functions like
mcount can't reach the ftrace helper functions which are written in C.
Avoid this problem of too distant branches by moving the ftrace C-helper
functions into the .text.hot section which is put in front of the
standard .text section by the linker.

Signed-off-by: Helge Deller

parisc: Fix ftrace function tracer

2016-04-14T15:47:19+00:00

Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.

Signed-off-by: Helge Deller

parisc: Add Huge Page and HUGETLBFS support

2015-11-22T11:23:10+00:00

This patch adds huge page support to allow userspace to allocate huge
pages and to use hugetlbfs filesystem on 32- and 64-bit Linux kernels.
A later patch will add kernel support to map kernel text and data on
huge pages.

The only requirement is, that the kernel needs to be compiled for a
PA8X00 CPU (PA2.0 architecture). Older PA1.X CPUs do not support
variable page sizes. 64bit Kernels are compiled for PA2.0 by default.

Technically on parisc multiple physical huge pages may be needed to
emulate standard 2MB huge pages.

Signed-off-by: Helge Deller