- May 10, 2019
-
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
This patch modifies the initial page mapping functions in the following way: During bootup the init, text and data pages will be mapped RWX and if supported, with huge pages. At final stage of the bootup, the kernel calls free_initmem() and then all pages will be remapped either R-X (for text and read-only data) or RW- (for data). The __init pages will be dropped. This reflects the behaviour of the x86 platform. Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
When running an SMP kernel on a single-CPU machine, we can speed up the CAS code by replacing the LDCW sync barrier with NOP. Signed-off-by:
Helge Deller <deller@gmx.de>
-
- May 05, 2019
-
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
LEVEL is a very common word, and now after many years it suddenly clashed with another LEVEL define in the DRBD code. Rename it to PA_ASM_LEVEL instead. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org>
-
- May 03, 2019
-
-
Mikulas Patocka authored
PA-RISC uses a global spinlock to protect pagetable updates in the TLB fault handlers. When multiple cores are taking TLB faults simultaneously, the cache line containing the spinlock becomes a bottleneck. This patch embeds the spinlock in the top level page directory, so that every process has its own lock. It improves performance by 30% when doing parallel compilations. At least on the N class systems, only one PxTLB inter processor broadcast can be active at any one time on the Merced bus. If a Merced bus is found, this patch serializes the TLB flushes with the pa_tlb_flush_lock spinlock. v1: Initial patch by Mikulas v2: Added Merced detection by Helge v3: Revised TLB serialization by Dave & Helge Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de>
-
John David Anglin authored
There are only a couple of instructions that can function as a memory barrier on parisc. Currently, we use the sync instruction as a memory barrier when releasing a spinlock. However, the ldcw instruction is a better barrier when we have a handy memory location since it operates in the cache on coherent machines. This patch updates the spinlock release code to use ldcw. I also changed the "stw,ma" instructions to "stw" instructions as it is not an adequate barrier. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
Helge Deller <deller@gmx.de>
-
John David Anglin authored
TLB operations only need to be serialized on machines with the Merced (Stretch) bus. The only machines in this category are L and N class, and they require a 64-bit PA 2.0 kernel. On these machines, we use local TLB purges in the tmpalias routines. We don't need to serialize TLB purges on all other machines. Thus, the lock/unlock code can be removed when CONFIG_PA20 is not defined. Further, when CONFIG_PA20 is not defined, alternative patching converts the TLB purges to local purges when PA 2.0 hardware has been detected. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Tested-By:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
The commit 1c30844d ("mm: reclaim small amounts of memory when an external fragmentation event occurs") breaks memory management on a parisc c8000 workstation with this memory layout: 0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB 1) Start 0x0000000100000000 End 0x00000001bfdfffff Size 3070 MB 2) Start 0x0000004040000000 End 0x00000040ffffffff Size 3072 MB With the patch 1c30844d, the kernel will incorrectly reclaim the first zone when it fills up, ignoring the fact that there are two completely free zones. Basiscally, it limits cache size to 1GiB. The parisc kernel is currently using the DISCONTIGMEM implementation, but isn't NUMA. Avoid this issue or strange work-arounds by switching to the more commonly used SPARSEMEM implementation. Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Fixes: 1c30844d ("mm: reclaim small amounts of memory when an external fragmentation event occurs") Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
The idle task might have been allocated above 4GB. With the current code we cannot access that memory because the CPU is still running in narrow mode. This was found on a J5000 machine and the patch is required to enable SPARSEMEM on that machine. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
It's not used by patch_map()/patch_unmap(), so lets remove it. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
Implement kretprobes on parisc, parts stolen from powerpc. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
Implement kprobes support for PA-RISC. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
implement regs_get_register(), regs_get_kernel_stack_nth() and regs_within_kernel_stack() Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de> CC: stable@vger.kernel.org # v4.9+
-
Sven Schnelle authored
This patch add KGDB support to PA-RISC. It also implements single-stepping utilizing the recovery counter. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sven Schnelle authored
Instead of re-mapping the whole kernel text with RWX rights add a patch_text() which can be used to replace instructions in the kernel .text section. Based on the ARM implementation. Signed-off-by:
Sven Schnelle <svens@stackframe.org> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Alexandre Ghiti authored
Do not offset mmap base address because of stack randomization if current task does not want randomization. Signed-off-by:
Alexandre Ghiti <alex@ghiti.fr> Signed-off-by:
Helge Deller <deller@gmx.de>
-
- Apr 15, 2019
-
-
Arnd Bergmann authored
Add the io_uring and pidfd_send_signal system calls to all architectures. These system calls are designed to handle both native and compat tasks, so all entries are the same across architectures, only arm-compat and the generic tale still use an old format. Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> (s390) Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Apr 06, 2019
-
-
Helge Deller authored
While adding LASI support to QEMU, I noticed that the QEMU detection in the kernel happens much too late. For example, when a LASI chip is found by the kernel, it registers the LASI LED driver as well. But when we run on QEMU it makes sense to avoid spending unnecessary CPU cycles, so we need to access the running_on_QEMU flag earlier than before. This patch now makes the QEMU detection the fist task of the Linux kernel by moving it to where the kernel enters the C-coding. Fixes: 310d8278 ("parisc: qemu idle sleep support") Signed-off-by:
Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v4.14+
-
- Feb 21, 2019
-
-
Helge Deller authored
Ask PDC firmware during boot for the original and current product number as well as the serial number and show it (if available). Signed-off-by:
Helge Deller <deller@gmx.de>
-
Christoph Hellwig authored
No need for any of the definitions here, all there real work now happens out of line. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Sergey Senozhatsky authored
Use bust_spinlocks() function to set oops_in_progress. Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
On parisc, each IRQ can only be handled by one CPU, and currently CPU0 is choosen as default for handling all IRQs by default. With this patch we now assign each requested IRQ to one of the online CPUs (and thus distribute the IRQs across all CPUs), even without an instance of irqbalance running. Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Like other platforms, count the number of IPI function call interrupts and show it in /proc/interrupts. Signed-off-by:
Helge Deller <deller@gmx.de>
-
Helge Deller authored
Signed-off-by:
Helge Deller <deller@gmx.de>
-
Dmitry V. Levin authored
Commit 910cd32e ("parisc: Fix and enable seccomp filter support") introduced a regression in ptrace-based syscall tampering: when tracer changes syscall number to -1, the kernel fails to initialize %r28 with -ENOSYS and subsequently fails to return the error code of the failed syscall to userspace. This erroneous behaviour could be observed with a simple strace syscall fault injection command which is expected to print something like this: $ strace -a0 -ewrite -einject=write:error=enospc echo hello write(1, "hello\n", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "echo: ", 6) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "write error", 11) = -1 ENOSPC (No space left on device) (INJECTED) write(2, "\n", 1) = -1 ENOSPC (No space left on device) (INJECTED) +++ exited with 1 +++ After commit 910cd32e it loops printing something like this instead: write(1, "hello\n", 6../strace: Failed to tamper with process 12345: unexpectedly got no error (return value 0, error 0) ) = 0 (INJECTED) This bug was found by strace test suite. Fixes: 910cd32e ("parisc: Fix and enable seccomp filter support") Cc: stable@vger.kernel.org # v4.5+ Signed-off-by:
Dmitry V. Levin <ldv@altlinux.org> Tested-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Helge Deller <deller@gmx.de>
-
- Feb 06, 2019
-
-
Arnd Bergmann authored
This adds 21 new system calls on each ABI that has 32-bit time_t today. All of these have the exact same semantics as their existing counterparts, and the new ones all have macro names that end in 'time64' for clarification. This gets us to the point of being able to safely use a C library that has 64-bit time_t in user space. There are still a couple of loose ends to tie up in various areas of the code, but this is the big one, and should be entirely uncontroversial at this point. In particular, there are four system calls (getitimer, setitimer, waitid, and getrusage) that don't have a 64-bit counterpart yet, but these can all be safely implemented in the C library by wrapping around the existing system calls because the 32-bit time_t they pass only counts elapsed time, not time since the epoch. They will be dealt with later. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Catalin Marinas <catalin.marinas@arm.com>
-
Arnd Bergmann authored
The time, stime, utime, utimes, and futimesat system calls are only used on older architectures, and we do not provide y2038 safe variants of them, as they are replaced by clock_gettime64, clock_settime64, and utimensat_time64. However, for consistency it seems better to have the 32-bit architectures that still use them call the "time32" entry points (leaving the traditional handlers for the 64-bit architectures), like we do for system calls that now require two versions. Note: We used to always define __ARCH_WANT_SYS_TIME and __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat mode. The resulting asm/unistd.h changes look a bit counterintuitive. This is only a cleanup patch and it should not change any behavior. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Heiko Carstens <heiko.carstens@de.ibm.com>
-
Arnd Bergmann authored
This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME and use the _time32 system calls from the former compat layer instead of the system calls that take __kernel_timespec and similar arguments. The temporary redirects for __kernel_timespec, __kernel_itimerspec and __kernel_timex can get removed with this. It would be easy to split this commit by architecture, but with the new generated system call tables, it's easy enough to do it all at once, which makes it a little easier to check that the changes are the same in each table. Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
A lot of system calls that pass a time_t somewhere have an implementation using a COMPAT_SYSCALL_DEFINEx() on 64-bit architectures, and have been reworked so that this implementation can now be used on 32-bit architectures as well. The missing step is to redefine them using the regular SYSCALL_DEFINEx() to get them out of the compat namespace and make it possible to build them on 32-bit architectures. Any system call that ends in 'time' gets a '32' suffix on its name for that version, while the others get a '_time32' suffix, to distinguish them from the normal version, which takes a 64-bit time argument in the future. In this step, only 64-bit architectures are changed, doing this rename first lets us avoid touching the 32-bit architectures twice. Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- Jan 25, 2019
-
-
Arnd Bergmann authored
Most architectures define system call numbers for the rseq and pkey system calls, even when they don't support the features, and perhaps never will. Only a few architectures are missing these, so just define them anyway for consistency. If we decide to add them later to one of these, the system call numbers won't get out of sync then. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org>
-