linux-stable.git/arch/parisc/kernel/syscall.S, branch linux-4.1.y

parisc: Fix validity check of pointer size argument in new CAS implementation

2017-12-08T23:01:07+00:00

[ Upstream commit 05f016d2ca7a4fab99d5d5472168506ddf95e74f ]

As noted by Christoph Biedl, passing a pointer size of 4 in the new CAS
implementation causes a kernel crash.  The attached patch corrects the
off by one error in the argument validity check.

In reviewing the code, I noticed that we only perform word operations
with the pointer size argument.  The subi instruction intentionally uses
a word condition on 64-bit kernels.  Nullification was used instead of a
cmpib instruction as the branch should never be taken.  The shlw
pseudo-operation generates a depw,z instruction and it clears the target
before doing a shift left word deposit.  Thus, we don't need to clip the
upper 32 bits of this argument on 64-bit kernels.

Tested with a gcc testsuite run with a 64-bit kernel.  The gcc atomic
code in libgcc is the only direct user of the new CAS implementation
that I am aware of.

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

parisc: Fix double-word compare and exchange in LWS code on 32-bit kernels

2017-11-06T04:54:36+00:00

[ Upstream commit 374b3bf8e8b519f61eb9775888074c6e46b3bf0c ]

As discussed on the debian-hppa list, double-wordcompare and exchange
operations fail on 32-bit kernels.  Looking at the code, I realized that
the ",ma" completer does the wrong thing in the  "ldw,ma  4(%r26), %r29"
instruction.  This increments %r26 and causes the following store to
write to the wrong location.

Note by Helge Deller:
The patch applies cleanly to stable kernel series if this upstream
commit is merged in advance:
f4125cfdb300 ("parisc: Avoid trashing sr2 and sr3 in LWS code").

Signed-off-by: John David Anglin 
Tested-by: Christoph Biedl 
Fixes: 89206491201c ("parisc: Implement new LWS CAS supporting 64 bit operations.")
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

parisc: Avoid trashing sr2 and sr3 in LWS code

2017-11-06T04:54:36+00:00

[ Upstream commit f4125cfdb3008363137f744c101e5d76ead760ba ]

There is no need to trash sr2 and sr3 in the Light-weight syscall (LWS).  sr2
already points to kernel space (it's zero in userspace, otherwise syscalls
wouldn't work), and since the LWS code is executed in userspace, we can simply
ignore to preload sr3.

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

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

2016-11-26T03:57:03+00:00

[ Upstream commit 6ed518328d0189e0fdf1bb7c73290d546143ea66 ]

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.

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

parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

2016-05-17T17:43:03+00:00

[ Upstream commit f0b22d1bb2a37a665a969e95785c75a4f49d1499 ]

Do not load one entry beyond the end of the syscall table when the
syscall number of a traced process equals to __NR_Linux_syscalls.
Similar bug with regular processes was fixed by commit 3bb457af4fa8
("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls").

This bug was found by strace test suite.

Cc: stable@vger.kernel.org
Signed-off-by: Dmitry V. Levin 
Acked-by: Helge Deller 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

parisc: Fix ptrace syscall number and return value modification

2016-03-09T18:15:23+00:00

[ Upstream commit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 ]

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 
Cc: stable@vger.kernel.org  # v4.0+
Tested-by: Mike Frysinger 
Signed-off-by: Sasha Levin

parisc: Use double word condition in 64bit CAS operation

2015-09-29T17:26:11+00:00

commit 1b59ddfcf1678de38a1f8ca9fb8ea5eebeff1843 upstream.

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.

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

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