linux-toradex.git/arch/parisc/kernel/syscall.S, branch v4.4.89

parisc: Ensure consistent state when switching to kernel stack at syscall entry

2016-11-10T15:36:34+00:00

commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 upstream.

We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.

This patch now disables interrupts while executing the critical section.  This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.

Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.

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

parisc: Fix ptrace syscall number and return value modification

2016-03-09T23:34:50+00:00

commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 upstream.

Mike Frysinger reported that his ptrace testcase showed strange
behaviour on parisc: It was not possible to avoid a syscall and the
return value of a syscall couldn't be changed.

To modify a syscall number, we were missing to save the new syscall
number to gr20 which is then picked up later in assembly again.

The effect that the return value couldn't be changed is a side-effect of
another bug in the assembly code. When a process is ptraced, userspace
expects each syscall to report entrance and exit of a syscall.  If a
syscall number was given which doesn't exist, we jumped to the normal
syscall exit code instead of informing userspace that the (non-existant)
syscall exits. This unexpected behaviour confuses userspace and thus the
bug was misinterpreted as if we can't change the return value.

This patch fixes both problems and was tested on 64bit kernel with
32bit userspace.

Signed-off-by: Helge Deller 
Cc: Mike Frysinger 
Tested-by: Mike Frysinger 
Signed-off-by: Greg Kroah-Hartman

parisc: Use long branch to do_syscall_trace_exit

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

Use the 22bit instead of the 17bit branch instruction on a 64bit kernel
to reach the do_syscall_trace_exit function from the gateway page.
A huge page enabled kernel may need the additional branch distance bits.

Signed-off-by: Helge Deller

parisc: Use double word condition in 64bit CAS operation

2015-09-08T14:15:54+00:00

The attached change fixes the condition used in the "sub" instruction.
A double word comparison is needed.  This fixes the 64-bit LWS CAS
operation on 64-bit kernels.

I can now enable 64-bit atomic support in GCC.

Cc: 
Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller

parisc: Implement new LWS CAS supporting 64 bit operations.

2014-09-13T20:40:48+00:00

The current LWS cas only works correctly for 32bit. The new LWS allows
for CAS operations of variable size.

Signed-off-by: Guy Martin 
Cc:  # 3.13+
Signed-off-by: Helge Deller

parisc: Improve LWS-CAS performance

2014-05-15T19:12:26+00:00

The attached change significantly improves the performance of the LWS-CAS code
in syscall.S.
This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
that previously failed because slow LWS-CAS performance under contention. In
particular, interrupts taken while the lock was taken degraded performance
significantly.

The change does the following:

1) Disables interrupts around the CAS operation, and
2) Changes the loads and stores to use the ordered completer, "o", on
PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
accepted on both PA 1.X and 2.0.

The use of ordered loads and stores probably makes no difference on all
existing hardware, but it seemed pedantically correct. In particular, the CAS
operation must complete before LDCW lock is released. As written before, a
processor could reorder the operations.

I don't believe the period interrupts are disabled is long enough to
significantly increase interrupt latency. For example, the TLB insert code is
longer. Worst case is a memory fault in the CAS operation.

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

parisc: provide macro to create exception table entries

2013-11-07T21:25:33+00:00

Provide a macro ASM_EXCEPTIONTABLE_ENTRY() to create exception table
entries and convert all open-coded places to use that macro.

This patch is a first step toward creating a exception table which only
holds 32bit pointers even on a 64bit kernel. That way in my own kernel
I was able to reduce the in-kernel exception table from 44kB to 22kB.

Signed-off-by: Helge Deller

parisc: document the parisc gateway page

2013-05-06T21:09:10+00:00

Include some documentation about how the parisc gateway page technically
works and how it is used from userspace.

James Bottomley is the original author of this description and it was
copied here out of an email thread from Apr 12 2013 titled:
man2 : syscall.2 : document syscall calling conventions

CC: James Bottomley 
Signed-off-by: Helge Deller

parisc: fix partly 16/64k PAGE_SIZE boot

2013-05-06T21:08:32+00:00

This patch fixes partly PAGE_SIZEs of 16K or 64K by adjusting the
assembler PTE lookup code and the assembler TEMPALIAS code.  Furthermore
some data alignments for PAGE_SIZE have been limited to 4K (or less) to
not waste too much memory with greater page sizes. As a side note, the
palo loader can (currently) only handle up to 10 ELF segments which is
fixed with tighter aligning as well.

My testings indicated that the ldci command in the sba iommu coding
needed adjustment by the PAGE_SHIFT value and that the I/O PDIR Page
size was only set to 4K for my machine (C3000).

All this fixes partly the boot, but there are still quite some caching
problems left.  Examples are e.g. the symbios logic driver which is
failing:

sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 69
sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
CACHE TEST FAILED: DMA error (dstat=0x81).sym0: CACHE INCORRECTLY CONFIGURED.

and the tulip network driver which doesn't seem to work correctly
either:

Sending BOOTP requests .net eth0: Setting full-duplex based on MII#1
link partner capability of 05e1
..... timed out!

Beside those kernel fixes glibc will need fixes too to be able to handle
>4K page sizes.

Signed-off-by: Helge Deller

parisc: fix ptrace breakage

2013-02-20T21:51:11+00:00

1) PTRACE_SYSCALL doesn't work for 64bit process on parisc64.
Compat syscall table is used instead of 64bit one.  IMO we should either
refuse to allow PTRACE_SYSCALL for 64bit processes or duplicate the
logics choosing the right syscall table into .Ltracesys.

	2) if you have let the tracee run with PTRACE_SYSCALL and
it had stopped, you can use PTRACE_POKEUSR to modify syscall number
(r20) and arguments 1--4 (r26--r23).  Modifications will have effect.
However, modifying arguments 5 and 6 (r22 and r21 resp.) works only
when process (32bit one) runs on 64bit host - on 32bit one it has no
effect.  AFAICS, the diff below should fix that one.

Signed-off-by: Al Viro 
Tested-by: John David Anglin 
Signed-off-by: Helge Deller