linux-stable.git/arch/parisc/kernel/entry.S, branch linux-4.9.y

parisc/entry: fix trace test in syscall exit path

2021-11-26T10:48:40+00:00

commit 3ec18fc7831e7d79e2d536dd1f3bc0d3ba425e8a upstream.

commit 8779e05ba8aa ("parisc: Fix ptrace check on syscall return")
fixed testing of TI_FLAGS. This uncovered a bug in the test mask.
syscall_restore_rfi is only used when the kernel needs to exit to
usespace with single or block stepping and the recovery counter
enabled. The test however used _TIF_SYSCALL_TRACE_MASK, which
includes a lot of bits that shouldn't be tested here.

Fix this by using TIF_SINGLESTEP and TIF_BLOCKSTEP directly.

I encountered this bug by enabling syscall tracepoints. Both in qemu and
on real hardware. As soon as i enabled the tracepoint (sys_exit_read,
but i guess it doesn't really matter which one), i got random page
faults in userspace almost immediately.

Signed-off-by: Sven Schnelle 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Fix ptrace check on syscall return

2021-11-26T10:48:18+00:00

commit 8779e05ba8aaffec1829872ef9774a71f44f6580 upstream.

The TIF_XXX flags are stored in the flags field in the thread_info
struct (TI_FLAGS), not in the flags field of the task_struct structure
(TASK_FLAGS).

It seems this bug didn't generate any important side-effects, otherwise it
wouldn't have went unnoticed for 12 years (since v2.6.32).

Signed-off-by: Helge Deller 
Fixes: ecd3d4bc06e48 ("parisc: stop using task->ptrace for {single,block}step flags")
Cc: Kyle McMartin 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

parisc: Fix address in HPMC IVA

2018-11-13T19:16:46+00:00

commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream.

Helge noticed that the address of the os_hpmc handler was not being
correctly calculated in the hpmc macro.  As a result, PDCE_CHECK would
fail to call os_hpmc:

 e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
 f600105e02e00000  fffffff0f0c00000  CC_MC_HPMC_MONARCH_SELECTED
 140003b202e00000  000000000000000b  CC_ERR_HPMC_STATE_ENTRY
 5600100b02e00000  00000000000001a0  CC_MC_OS_HPMC_LEN_ERR
 5600106402e00000  fffffff0f0438e70  CC_MC_BR_TO_OS_HPMC_FAILED
 e800009802e00000  0000000000000000  CC_ERR_CHECK_HPMC
 37000f7302e00000  8040004000000000  CC_ERR_CPU_CHECK_SUMMARY
 4000109f02e00000  0000000000000000  CC_MC_HPMC_INITIATED
 4000101902e00000  0000000000000000  CC_MC_MULTIPLE_HPMCS
 030010d502e00000  0000000000000000  CC_CPU_STOP

The address problem can be seen by dumping the fault vector:

0000000040159000 :
    40159000:   63 6f 77 73     stb r15,-2447(dp)
    40159004:   20 63 61 6e     ldil L%b747000,r3
    40159008:   20 66 6c 79     ldil L%-1c3b3000,r3
        ...
    40159020:   08 00 02 40     nop
    40159024:   20 6e 60 02     ldil L%15d000,r3
    40159028:   34 63 00 00     ldo 0(r3),r3
    4015902c:   e8 60 c0 02     bv,n r0(r3)
    40159030:   08 00 02 40     nop
    40159034:   00 00 00 00     break 0,0
    40159038:   c0 00 70 00     bb,*< r0,sar,40159840 
    4015903c:   00 00 00 00     break 0,0

Location 40159038 should contain the physical address of os_hpmc:

000000004015d000 :
    4015d000:   08 1a 02 43     copy r26,r3
    4015d004:   01 c0 08 a4     mfctl iva,r4
    4015d008:   48 85 00 68     ldw 34(r4),r5

This patch moves the address setup into initialize_ivt to resolve the
above problem.  I tested the change by dumping the HPMC entry after setup:

0000000040209020:  8000240
0000000040209024: 206a2004
0000000040209028: 34630ac0
000000004020902c: e860c002
0000000040209030:  8000240
0000000040209034: 1bdddce6
0000000040209038:   15d000
000000004020903c:      1a0

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

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

2018-08-15T16:14:41+00:00

commit fedb8da96355f5f64353625bf96dc69423ad1826 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

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

2018-01-10T08:29:54+00:00

commit 88776c0e70be0290f8357019d844aae15edaa967 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

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