linux.git/arch/parisc, branch v5.4.64

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

2020-09-03T09:27:10+00:00

commit e4a42c82e943b97ce124539fcd7a47445b43fa0d upstream.

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov 
Tested-by: Guenter Roeck 
Signed-off-by: Masahiro Yamada 
Cc: Matthias Maennich 
Signed-off-by: Greg Kroah-Hartman

kbuild: add variables for compression tools

2020-09-03T09:27:10+00:00

commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream.

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2

Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.

The credit goes to @grsecurity.

As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"

Signed-off-by: Denis Efremov 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Matthias Maennich 
Signed-off-by: Greg Kroah-Hartman

parisc: Implement __smp_store_release and __smp_load_acquire barriers

2020-08-19T06:16:26+00:00

commit e96ebd589debd9a6a793608c4ec7019c38785dea upstream.

This patch implements the __smp_store_release and __smp_load_acquire barriers
using ordered stores and loads.  This avoids the sync instruction present in
the generic implementation.

Cc:  # 4.14+
Signed-off-by: Dave Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Do not use an ordered store in pa_tlb_lock()

2020-08-19T06:16:26+00:00

commit e72b23dec1da5e62a0090c5da1d926778284e230 upstream.

No need to use an ordered store in pa_tlb_lock() and update the comment
regarng usage of the sid register to unlocak a spinlock in
tlb_unlock0().

Signed-off-by: John David Anglin 
Signed-off-by: Helge Deller 
Cc:  # v5.0+
Signed-off-by: Greg Kroah-Hartman

Revert "parisc: Revert "Release spinlocks using ordered store""

2020-08-19T06:16:26+00:00

commit 157e9afcc4fa25068b0e8743bc254a9b56010e13 upstream.

This reverts commit 86d4d068df573a8c2105554624796c086d6bec3d.

Signed-off-by: Helge Deller 
Cc:  # v5.0+
Signed-off-by: Greg Kroah-Hartman

Revert "parisc: Use ldcw instruction for SMP spinlock release barrier"

2020-08-19T06:16:26+00:00

commit 6e9f06ee6c9566f3606d93182ac8f803a148504b upstream.

This reverts commit 9e5c602186a692a7e848c0da17aed40f49d30519.
No need to use the ldcw instruction as SMP spinlock release barrier.
Revert it to gain back speed again.

Signed-off-by: Helge Deller 
Cc:  # v5.2+
Signed-off-by: Greg Kroah-Hartman

Revert "parisc: Drop LDCW barrier in CAS code when running UP"

2020-08-19T06:16:26+00:00

commit 462fb756c7de1ffe5bc6099149136031c2d9c02a upstream.

This reverts commit e6eb5fe9123f05dcbf339ae5c0b6d32fcc0685d5.
We need to optimize it differently. A follow up patch will correct it.

Signed-off-by: Helge Deller 
Cc:  # v5.2+
Signed-off-by: Greg Kroah-Hartman

parisc: add support for cmpxchg on u8 pointers

2020-08-05T07:59:50+00:00

[ Upstream commit b344d6a83d01c52fddbefa6b3b4764da5b1022a0 ]

The kernel test bot reported[1] that using set_mask_bits on a u8 causes
the following issue on parisc:

	hppa-linux-ld: drivers/phy/ti/phy-tusb1210.o: in function `tusb1210_probe':
	>> (.text+0x2f4): undefined reference to `__cmpxchg_called_with_bad_pointer'
	>> hppa-linux-ld: (.text+0x324): undefined reference to `__cmpxchg_called_with_bad_pointer'
	hppa-linux-ld: (.text+0x354): undefined reference to `__cmpxchg_called_with_bad_pointer'

Add support for cmpxchg on u8 pointers.

[1] https://lore.kernel.org/patchwork/patch/1272617/#1468946

Reported-by: kernel test robot 
Signed-off-by: Liam Beguin 
Tested-by: Dave Anglin 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

parisc: Add atomic64_set_release() define to avoid CPU soft lockups

2020-07-29T08:18:45+00:00

commit be6577af0cef934ccb036445314072e8cb9217b9 upstream.

Stalls are quite frequent with recent kernels. I enabled
CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall:

watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803]
CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3
Hardware name: 9000/800/rp3440
 IAOQ[0]: d_alloc_parallel+0x384/0x688
 IAOQ[1]: d_alloc_parallel+0x388/0x688
 RP(r2): d_alloc_parallel+0x134/0x688
Backtrace:
 [<000000004036974c>] __lookup_slow+0xa4/0x200
 [<0000000040369fc8>] walk_component+0x288/0x458
 [<000000004036a9a0>] path_lookupat+0x88/0x198
 [<000000004036e748>] filename_lookup+0xa0/0x168
 [<000000004036e95c>] user_path_at_empty+0x64/0x80
 [<000000004035d93c>] vfs_statx+0x104/0x158
 [<000000004035dfcc>] __do_sys_lstat64+0x44/0x80
 [<000000004035e5a0>] sys_lstat64+0x20/0x38
 [<0000000040180054>] syscall_exit+0x0/0x14

The code was stuck in this loop in d_alloc_parallel:

    4037d414:   0e 00 10 dc     ldd 0(r16),ret0
    4037d418:   c7 fc 5f ed     bb,< ret0,1f,4037d414 
    4037d41c:   08 00 02 40     nop

This is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in
d_alloc_parallel:

static inline void bit_spin_lock(int bitnum, unsigned long *addr)
{
        /*
         * Assuming the lock is uncontended, this never enters
         * the body of the outer loop. If it is contended, then
         * within the inner loop a non-atomic test is used to
         * busywait with less bus contention for a good time to
         * attempt to acquire the lock bit.
         */
        preempt_disable();
#if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
        while (unlikely(test_and_set_bit_lock(bitnum, addr))) {
                preempt_enable();
                do {
                        cpu_relax();
                } while (test_bit(bitnum, addr));
                preempt_disable();
        }
#endif
        __acquire(bitlock);
}

After consideration, I realized that we must be losing bit unlocks.
Then, I noticed that we missed defining atomic64_set_release().
Adding this define fixes the stalls in bit operations.

Signed-off-by: Dave Anglin 
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

parisc: Fix kernel panic in mem_init()

2020-06-03T06:21:28+00:00

[ Upstream commit bf71bc16e02162388808949b179d59d0b571b965 ]

The Debian kernel v5.6 triggers this kernel panic:

 Kernel panic - not syncing: Bad Address (null pointer deref?)
 Bad Address (null pointer deref?): Code=26 (Data memory access rights trap) at addr 0000000000000000
 CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-parisc64 #1 Debian 5.6.14-1
  IAOQ[0]: mem_init+0xb0/0x150
  IAOQ[1]: mem_init+0xb4/0x150
  RP(r2): start_kernel+0x6c8/0x1190
 Backtrace:
  [<0000000040101ab4>] start_kernel+0x6c8/0x1190
  [<0000000040108574>] start_parisc+0x158/0x1b8

on a HP-PARISC rp3440 machine with this memory layout:
 Memory Ranges:
  0) Start 0x0000000000000000 End 0x000000003fffffff Size   1024 MB
  1) Start 0x0000004040000000 End 0x00000040ffdfffff Size   3070 MB

Fix the crash by avoiding virt_to_page() and similar functions in
mem_init() until the memory zones have been fully set up.

Signed-off-by: Helge Deller 
Cc: stable@vger.kernel.org # v5.0+
Signed-off-by: Sasha Levin