20 Jan, 2021

3 commits

  • This is the 5.10.8 stable release

    * tag 'v5.10.8': (104 commits)
    Linux 5.10.8
    tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
    drm/panfrost: Remove unused variables in panfrost_job_close()
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.10.7 stable release

    * tag 'v5.10.7': (144 commits)
    Linux 5.10.7
    scsi: target: Fix XCOPY NAA identifier lookup
    rtlwifi: rise completion at the last step of firmware callback
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.10.5 stable release

    * tag 'v5.10.5': (63 commits)
    Linux 5.10.5
    device-dax: Fix range release
    ext4: avoid s_mb_prefetch to be zero in individual scenarios
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     

17 Jan, 2021

1 commit

  • [ Upstream commit 98bf2d3f4970179c702ef64db658e0553bc6ef3a ]

    When we have VMAP stack, exception prolog 1 sets r1, not r11.

    When it is not an RTAS machine check, don't trash r1 because it is
    needed by prolog 1.

    Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before activating MMU")
    Fixes: d2e006036082 ("powerpc/32: Use SPRN_SPRG_SCRATCH2 in exception prologs")
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Christophe Leroy
    [mpe: Squash in fixup for RTAS machine check from Christophe]
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/bc77d61d1c18940e456a2dee464f1e2eda65a3f0.1608621048.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin

    Christophe Leroy
     

13 Jan, 2021

2 commits

  • commit 3ce47d95b7346dcafd9bed3556a8d072cb2b8571 upstream.

    Commit eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input
    sections") added ".text.unlikely.*" and ".text.hot.*" due to an LLVM
    change [1].

    After another LLVM change [2], these sections are seen in some PowerPC
    builds, where there is a orphan section warning then build failure:

    $ make -skj"$(nproc)" \
    ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- LLVM=1 O=out \
    distclean powernv_defconfig zImage.epapr
    ld.lld: warning: kernel/built-in.a(panic.o):(.text.unlikely.) is being placed in '.text.unlikely.'
    ...
    ld.lld: warning: address (0xc000000000009314) of section .text is not a multiple of alignment (256)
    ...
    ERROR: start_text address is c000000000009400, should be c000000000008000
    ERROR: try to enable LD_HEAD_STUB_CATCH config option
    ERROR: see comments in arch/powerpc/tools/head_check.sh
    ...

    Explicitly handle these sections like in the main linker script so
    there is no more build failure.

    [1]: https://reviews.llvm.org/D79600
    [2]: https://reviews.llvm.org/D92493

    Fixes: 83a092cf95f2 ("powerpc: Link warning for orphan sections")
    Cc: stable@vger.kernel.org
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Michael Ellerman
    Link: https://github.com/ClangBuiltLinux/linux/issues/1218
    Link: https://lore.kernel.org/r/20210104205952.1399409-1-natechancellor@gmail.com
    Signed-off-by: Greg Kroah-Hartman

    Nathan Chancellor
     
  • [ Upstream commit 87dbc209ea04645fd2351981f09eff5d23f8e2e9 ]

    Make mandatory in include/asm-generic/Kbuild and
    remove all arch/*/include/asm/local64.h arch-specific files since they
    only #include .

    This fixes build errors on arch/c6x/ and arch/nios2/ for
    block/blk-iocost.c.

    Build-tested on 21 of 25 arch-es. (tools problems on the others)

    Yes, we could even rename to
    and change all #includes to use
    instead.

    Link: https://lkml.kernel.org/r/20201227024446.17018-1-rdunlap@infradead.org
    Signed-off-by: Randy Dunlap
    Suggested-by: Christoph Hellwig
    Reviewed-by: Masahiro Yamada
    Cc: Jens Axboe
    Cc: Ley Foon Tan
    Cc: Mark Salter
    Cc: Aurelien Jacquiot
    Cc: Peter Zijlstra
    Cc: Arnd Bergmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    Randy Dunlap
     

06 Jan, 2021

2 commits

  • [ Upstream commit 59d512e4374b2d8a6ad341475dc94c4a4bdec7d3 ]

    This is way to catch some cases of decrementer overflow, when the
    decrementer has underflowed an odd number of times, while MSR[EE] was
    disabled.

    With a typical small decrementer, a timer that fires when MSR[EE] is
    disabled will be "lost" if MSR[EE] remains disabled for between 4.3 and
    8.6 seconds after the timer expires. In any case, the decrementer
    interrupt would be taken at 8.6 seconds and the timer would be found at
    that point.

    So this check is for catching extreme latency events, and it prevents
    those latencies from being a further few seconds long. It's not obvious
    this is a good tradeoff. This is already a watchdog magnitude event and
    that situation is not improved a significantly with this check. For
    large decrementers, it's useless.

    Therefore remove this check, which avoids a mftb when enabling hard
    disabled interrupts (e.g., when enabling after coming from hardware
    interrupt handlers). Perhaps more importantly, it also removes the
    clunky MSR[EE] vs PACA_IRQ_HARD_DIS incoherency in soft-interrupt replay
    which simplifies the code.

    Signed-off-by: Nicholas Piggin
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201107014336.2337337-1-npiggin@gmail.com
    Signed-off-by: Sasha Levin

    Nicholas Piggin
     
  • [ Upstream commit ffa1797040c5da391859a9556be7b735acbe1242 ]

    I noticed that iounmap() of msgr_block_addr before return from
    mpic_msgr_probe() in the error handling case is missing. So use
    devm_ioremap() instead of just ioremap() when remapping the message
    register block, so the mapping will be automatically released on
    probe failure.

    Signed-off-by: Qinglang Miao
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201028091551.136400-1-miaoqinglang@huawei.com
    Signed-off-by: Sasha Levin

    Qinglang Miao
     

04 Jan, 2021

1 commit

  • This is the 5.10.4 stable release

    * tag 'v5.10.4': (717 commits)
    Linux 5.10.4
    x86/CPU/AMD: Save AMD NodeId as cpu_die_id
    drm/edid: fix objtool warning in drm_cvt_modes()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/gpu/drm/imx/dcss/dcss-plane.c
    drivers/media/i2c/ov5640.c

    Jason Liu
     

30 Dec, 2020

31 commits

  • commit d6718941a2767fb383e105d257d2105fe4f15f0e upstream.

    It's very easy to crash the kernel right now by simply trying to
    enable memtrace concurrently, hammering on the "enable" interface

    loop.sh:
    #!/bin/bash

    dmesg --console-off

    while true; do
    echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable
    done

    [root@localhost ~]# loop.sh &
    [root@localhost ~]# loop.sh &

    Resulting quickly in a kernel crash. Let's properly protect using a
    mutex.

    Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing")
    Cc: stable@vger.kernel.org# v4.14+
    Signed-off-by: David Hildenbrand
    Reviewed-by: Oscar Salvador
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201111145322.15793-3-david@redhat.com
    Signed-off-by: Greg Kroah-Hartman

    David Hildenbrand
     
  • commit c74cf7a3d59a21b290fe0468f5b470d0b8ee37df upstream.

    We currently leak kernel memory to user space, because memory
    offlining doesn't do any implicit clearing of memory and we are
    missing explicit clearing of memory.

    Let's keep it simple and clear pages before removing the linear
    mapping.

    Reproduced in QEMU/TCG with 10 GiB of main memory:
    [root@localhost ~]# dd obs=9G if=/dev/urandom of=/dev/null
    [... wait until "free -m" used counter no longer changes and cancel]
    19665802+0 records in
    1+0 records out
    9663676416 bytes (9.7 GB, 9.0 GiB) copied, 135.548 s, 71.3 MB/s
    [root@localhost ~]# cat /sys/devices/system/memory/block_size_bytes
    40000000
    [root@localhost ~]# echo 0x40000000 > /sys/kernel/debug/powerpc/memtrace/enable
    [ 402.978663][ T1086] page:000000001bc4bc74 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24900
    [ 402.980063][ T1086] flags: 0x7ffff000001000(reserved)
    [ 402.980415][ T1086] raw: 007ffff000001000 c00c000000924008 c00c000000924008 0000000000000000
    [ 402.980627][ T1086] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
    [ 402.980845][ T1086] page dumped because: unmovable page
    [ 402.989608][ T1086] Offlined Pages 16384
    [ 403.324155][ T1086] memtrace: Allocated trace memory on node 0 at 0x0000000200000000

    Before this patch:
    [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head
    00000000 c8 25 72 51 4d 26 36 c5 5c c2 56 15 d5 1a cd 10 |.%rQM&6.\.V.....|
    00000010 19 b9 50 b2 cb e3 60 b8 ec 0a f3 ec 4b 3c 39 f0 |..P...`.....K..o.j..R.n...]|$
    00000040 76 b3 ae b5 88 d7 da e3 64 23 85 2c 10 88 07 b6 |v.......d#.,....|$
    00000050 9a d8 91 de f7 50 27 69 2e 64 9c 6f d3 19 45 79 |.....P'i.d.o..Ey|$
    00000060 6a 6f 8a 61 71 19 1f c7 f1 df 28 26 ca 0f 84 55 |jo.aq.....(&...U|$
    00000070 01 3f be e4 e2 e1 da ff 7b 8c 8e 32 37 b4 24 53 |.?......{..27.$S|$
    00000080 1b 70 30 45 56 e6 8c c4 0e b5 4c fb 9f dd 88 06 |.p0EV.....L.....|$
    00000090 ef c4 18 79 f1 60 b1 5c 79 59 4d f4 36 d7 4a 5c |...y.`.\yYM.6.J\|$

    After this patch:
    [root@localhost ~]# hexdump -C /sys/kernel/debug/powerpc/memtrace/00000000/trace | head
    00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
    *
    40000000

    Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing")
    Cc: stable@vger.kernel.org # v4.14+
    Reported-by: Michael Ellerman
    Signed-off-by: David Hildenbrand
    Reviewed-by: Oscar Salvador
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201111145322.15793-2-david@redhat.com
    Signed-off-by: Greg Kroah-Hartman

    David Hildenbrand
     
  • commit b1198a88230f2ce50c271e22b82a8b8610b2eea9 upstream.

    We execute certain NPU2 setup code (such as mapping an LPID to a device
    in NPU2) unconditionally if an Nvlink bridge is detected. However this
    cannot succeed on POWER8NVL machines and errors appear in dmesg. This is
    harmless as skiboot returns an error and the only place we check it is
    vfio-pci but that code does not get called on P8+ either.

    This adds a check if pnv_npu2_xxx helpers are called on a machine with
    NPU2 which initializes pnv_phb::npu in pnv_npu2_init();
    pnv_phb::npu==NULL on POWER8/NVL (Naples).

    While at this, fix NULL derefencing in pnv_npu_peers_take_ownership/
    pnv_npu_peers_release_ownership which occurs when GPUs on mentioned P8s
    cause EEH which happens if "vfio-pci" disables devices using
    the D3 power state; the vfio-pci's disable_idle_d3 module parameter
    controls this and must be set on Naples. The EEH handling clears
    the entire pnv_ioda_pe struct in pnv_ioda_free_pe() hence
    the NULL derefencing. We cannot recover from that but at least we stop
    crashing.

    Tested on
    - POWER9 pvr=004e1201, Ubuntu 19.04 host, Ubuntu 18.04 vm,
    NVIDIA GV100 10de:1db1 driver 418.39
    - POWER8 pvr=004c0100, RHEL 7.6 host, Ubuntu 16.10 vm,
    NVIDIA P100 10de:15f9 driver 396.47

    Fixes: 1b785611e119 ("powerpc/powernv/npu: Add release_ownership hook")
    Cc: stable@vger.kernel.org # 5.0
    Signed-off-by: Alexey Kardashevskiy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201122073828.15446-1-aik@ozlabs.ru
    Signed-off-by: Greg Kroah-Hartman

    Alexey Kardashevskiy
     
  • commit 17179aeb9d34cc81e1a4ae3f85e5b12b13a1f8d0 upstream.

    MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature()

    Use mmu_has_feature() instead

    Fixes: 23eb7f560a2a ("powerpc: Convert flush_icache_range & friends to C")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/ceede82fadf37f3b8275e61fcf8cf29a3e2ec7fe.1602351011.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit 1e78f723d6a52966bfe3804209dbf404fdc9d3bb upstream.

    When SMC1 is relocated and early debug is selected, the
    board hangs is ppc_md.setup_arch(). This is because ones
    the microcode has been loaded and SMC1 relocated, early
    debug writes in the weed.

    To allow smooth continuation, the SMC1 parameter RAM set up
    by the bootloader have to be copied into the new location.

    Fixes: 43db76f41824 ("powerpc/8xx: Add microcode patch to move SMC parameter RAM.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/b2f71f39eca543f1e4ec06596f09a8b12235c701.1607076683.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit 7c6c86b36a36dd4a13d30bba07718e767aa2e7a1 upstream.

    Since some time now, printk() adds carriage return, leading to
    unusable xmon output if there is no udbg backend available:

    [ 54.288722] sysrq: Entering xmon
    [ 54.292209] Vector: 0 at [cace3d2c]
    [ 54.292274] pc:
    [ 54.292331] c0023650
    [ 54.292468] : xmon+0x28/0x58
    [ 54.292519]
    [ 54.292574] lr:
    [ 54.292630] c0023724
    [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc
    [ 54.292801]
    [ 54.292867] sp: cace3de8
    [ 54.292931] msr: 9032
    [ 54.292999] current = 0xc28d0000
    [ 54.293072] pid = 377, comm = sh
    [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty (root@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020
    [ 54.293287] enter ? for help
    [ 54.293470] [cace3de8]
    [ 54.293532] c0023724
    [ 54.293654] sysrq_handle_xmon+0xa4/0xfc
    [ 54.293711] (unreliable)
    ...
    [ 54.296002]
    [ 54.296159] --- Exception: c01 (System Call) at
    [ 54.296217] 0fd4e784
    [ 54.296303]
    [ 54.296375] SP (7fca6ff0) is in userspace
    [ 54.296431] mon>
    [ 54.296484]

    Use pr_cont() instead.

    Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
    Cc: stable@vger.kernel.org # v4.9+
    Signed-off-by: Christophe Leroy
    [mpe: Mention that it only happens when udbg is not available]
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/c8a6ec704416ecd5ff2bd26213c9bc026bdd19de.1607077340.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit 197493af414ee22427be3343637ac290a791925a upstream.

    G2_LE has a 603 core, add CPU_FTR_NOEXECUTE.

    Fixes: 385e89d5b20f ("powerpc/mm: add exec protection on powerpc 603")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/39a530ee41d83f49747ab3af8e39c056450b9b4d.1602489653.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit 1891ef21d92c4801ea082ee8ed478e304ddc6749 upstream.

    fls() and fls64() are using __builtin_ctz() and _builtin_ctzll().
    On powerpc, those builtins trivially use ctlzw and ctlzd power
    instructions.

    Allthough those instructions provide the expected result with
    input argument 0, __builtin_ctz() and __builtin_ctzll() are
    documented as undefined for value 0.

    The easiest fix would be to use fls() and fls64() functions
    defined in include/asm-generic/bitops/builtin-fls.h and
    include/asm-generic/bitops/fls64.h, but GCC output is not optimal:

    00000388 :
    388: 2c 03 00 00 cmpwi r3,0
    38c: 41 82 00 10 beq 39c
    390: 7c 63 00 34 cntlzw r3,r3
    394: 20 63 00 20 subfic r3,r3,32
    398: 4e 80 00 20 blr
    39c: 38 60 00 00 li r3,0
    3a0: 4e 80 00 20 blr

    000003b0 :
    3b0: 2c 03 00 00 cmpwi r3,0
    3b4: 40 82 00 1c bne 3d0
    3b8: 2f 84 00 00 cmpwi cr7,r4,0
    3bc: 38 60 00 00 li r3,0
    3c0: 4d 9e 00 20 beqlr cr7
    3c4: 7c 83 00 34 cntlzw r3,r4
    3c8: 20 63 00 20 subfic r3,r3,32
    3cc: 4e 80 00 20 blr
    3d0: 7c 63 00 34 cntlzw r3,r3
    3d4: 20 63 00 40 subfic r3,r3,64
    3d8: 4e 80 00 20 blr

    When the input of fls(x) is a constant, just check x for nullity and
    return either 0 or __builtin_clz(x). Otherwise, use cntlzw instruction
    directly.

    For fls64() on PPC64, do the same but with __builtin_clzll() and
    cntlzd instruction. On PPC32, lets take the generic fls64() which
    will use our fls(). The result is as expected:

    00000388 :
    388: 7c 63 00 34 cntlzw r3,r3
    38c: 20 63 00 20 subfic r3,r3,32
    390: 4e 80 00 20 blr

    000003a0 :
    3a0: 2c 03 00 00 cmpwi r3,0
    3a4: 40 82 00 10 bne 3b4
    3a8: 7c 83 00 34 cntlzw r3,r4
    3ac: 20 63 00 20 subfic r3,r3,32
    3b0: 4e 80 00 20 blr
    3b4: 7c 63 00 34 cntlzw r3,r3
    3b8: 20 63 00 40 subfic r3,r3,64
    3bc: 4e 80 00 20 blr

    Fixes: 2fcff790dcb4 ("powerpc: Use builtin functions for fls()/__fls()/fls64()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christophe Leroy
    Acked-by: Segher Boessenkool
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/348c2d3f19ffcff8abe50d52513f989c4581d000.1603375524.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit f10881a46f8914428110d110140a455c66bdf27b upstream.

    Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
    introduced the following error when invoking the errinjct userspace
    tool:

    [root@ltcalpine2-lp5 librtas]# errinjct open
    [327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
    [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
    errinjct: Could not open RTAS error injection facility
    errinjct: librtas: open: Unexpected I/O error

    The entry for ibm,open-errinjct in rtas_filter array has a typo where
    the "j" is omitted in the rtas call name. After fixing this typo the
    errinjct tool functions again as expected.

    [root@ltcalpine2-lp5 linux]# errinjct open
    RTAS error injection facility open, token = 1

    Fixes: bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tyrel Datwyler
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201208195434.8289-1-tyreld@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman

    Tyrel Datwyler
     
  • commit d85be8a49e733dcd23674aa6202870d54bf5600d upstream.

    The placeholder for instruction selection should use the second
    argument's operand, which is %1, not %0. This could generate incorrect
    assembly code if the memory addressing of operand %0 is a different
    form from that of operand %1.

    Also remove the %Un placeholder because having %Un placeholders
    for two operands which are based on the same local var (ptep) doesn't
    make much sense. By the way, it doesn't change the current behaviour
    because "<>" constraint is missing for the associated "=m".

    [chleroy: revised commit log iaw segher's comments and removed %U0]

    Fixes: 9bf2b5cdc5fe ("powerpc: Fixes for CONFIG_PTE_64BIT for SMP support")
    Cc: # v2.6.28+
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Christophe Leroy
    Acked-by: Segher Boessenkool
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/96354bd77977a6a933fe9020da57629007fdb920.1603358942.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Mathieu Desnoyers
     
  • commit d5c243989fb0cb03c74d7340daca3b819f706ee7 upstream.

    We need r1 to be properly set before activating MMU, otherwise any new
    exception taken while saving registers into the stack in syscall
    prologs will use the user stack, which is wrong and will even lockup
    or crash when KUAP is selected.

    Do that by switching the meaning of r11 and r1 until we have saved r1
    to the stack: copy r1 into r11 and setup the new stack pointer in r1.
    To avoid complicating and impacting all generic and specific prolog
    code (and more), copy back r1 into r11 once r11 is save onto
    the stack.

    We could get rid of copying r1 back and forth at the cost of rewriting
    everything to use r1 instead of r11 all the way when CONFIG_VMAP_STACK
    is set, but the effort is probably not worth it for now.

    Fixes: da7bb43ab9da ("powerpc/32: Fix vmap stack - Properly set r1 before activating MMU")
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/a3d819d5c348cee9783a311d5d3f3ba9b48fd219.1608531452.git.christophe.leroy@csgroup.eu
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • commit aa8e21c053d72b6639ea5a7f1d3a1d0209534c94 upstream.

    Perf event attritube supports exclude_kernel flag to avoid
    sampling/profiling in supervisor state (kernel). Based on this event
    attr flag, Monitor Mode Control Register bit is set to freeze on
    supervisor state. But sometimes (due to hardware limitation), Sampled
    Instruction Address Register (SIAR) locks on to kernel address even
    when freeze on supervisor is set. Patch here adds a check to drop
    those samples.

    Cc: stable@vger.kernel.org
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1606289215-1433-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman

    Athira Rajeev
     
  • [ Upstream commit 9014eab6a38c60fd185bc92ed60f46cf99a462ab ]

    It fixes this link warning:

    WARNING: modpost: vmlinux.o(.text.unlikely+0x2d98): Section mismatch in reference from the function init_big_cores.isra.0() to the function .init.text:init_thread_group_cache_map()
    The function init_big_cores.isra.0() references
    the function __init init_thread_group_cache_map().
    This is often because init_big_cores.isra.0 lacks a __init
    annotation or the annotation of init_thread_group_cache_map is wrong.

    Fixes: 425752c63b6f ("powerpc: Detect the presence of big-cores via "ibm, thread-groups"")
    Signed-off-by: Cédric Le Goater
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201221074154.403779-1-clg@kaod.org
    Signed-off-by: Sasha Levin

    Cédric Le Goater
     
  • [ Upstream commit b36f835b636908e4122f2e17310b1dbc380a3b19 ]

    The lkp robot reported that some configs fail to build, for example
    mpc85xx_smp_defconfig, with:

    cc1: fatal error: opening output file arch/powerpc/boot/dts/fsl/.mpc8540ads.dtb.dts.tmp: No such file or directory

    This bisects to:
    cc8a51ca6f05 ("kbuild: always create directories of targets")

    Although that commit claims to be about in-tree builds, it somehow
    breaks out-of-tree builds. But presumably it's just exposing a latent
    bug in our Makefiles.

    We can fix it by adding to targets for dts/fsl in the same way that we
    do for dts.

    Fixes: cc8a51ca6f05 ("kbuild: always create directories of targets")
    Reported-by: kernel test robot
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201215032906.473460-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin

    Michael Ellerman
     
  • [ Upstream commit c1bea0a840ac75dca19bc6aa05575a33eb9fd058 ]

    Currently pmac32_defconfig with SMP=y doesn't build:

    arch/powerpc/platforms/powermac/smp.c:
    error: implicit declaration of function 'cleanup_cpu_mmu_context'

    It would be nice for consistency if all platforms clear mm_cpumask and
    flush TLBs on unplug, but the TLB invalidation bug described in commit
    01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from mm_cpumasks") only
    applies to 64s and for now we only have the TLB flush code for that
    platform.

    So just add an empty version for 32-bit Book3S.

    Fixes: 01b0f0eae081 ("powerpc/64s: Trim offlined CPUs from mm_cpumasks")
    Reported-by: Geert Uytterhoeven
    Signed-off-by: Nicholas Piggin
    [mpe: Change log based on comments from Nick]
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin

    Michael Ellerman
     
  • [ Upstream commit ef0e3b650f8ddc54bb70868852f50642ee3ae765 ]

    Threshold Event Counter Multiplier (TECM) is part of Monitor Mode
    Control Register A (MMCRA). This field along with Threshold Event
    Counter Exponent (TECE) is used to get threshould counter value.
    In Power10, this is a 8bit field, so patch fixes the
    current code to modify the MMCRA[TECM] extraction macro to
    handle this change. ISA v3.1 says this is a 7 bit field but
    POWER10 it's actually 8 bits which will hopefully be fixed
    in ISA v3.1 update.

    Fixes: 170a315f41c6 ("powerpc/perf: Support to export MMCRA[TEC*] field to userspace")
    Signed-off-by: Madhavan Srinivasan
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1608022578-1532-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin

    Madhavan Srinivasan
     
  • [ Upstream commit 1817de2f141c718f1a0ae59927ec003e9b144349 ]

    Recently added Power10 prefixed VSX instruction are included
    unconditionally in the kernel. If they are executed on a
    machine without VSX support, it might create issues. Fix that.
    Also fix one mnemonics spelling mistake in comment.

    Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores")
    Signed-off-by: Ravi Bangoria
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201011050908.72173-3-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin

    Ravi Bangoria
     
  • [ Upstream commit ef6879f8c8053cc3b493f400a06d452d7fb13650 ]

    Unconditional emulation of prefixed instructions will allow
    emulation of them on Power10 predecessors which might cause
    issues. Restrict that.

    Fixes: 3920742b92f5 ("powerpc sstep: Add support for prefixed fixed-point arithmetic")
    Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores")
    Signed-off-by: Balamuruhan S
    Signed-off-by: Ravi Bangoria
    Reviewed-by: Sandipan Das
    Reviewed-by: Daniel Axtens
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201011050908.72173-2-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin

    Balamuruhan S
     
  • [ Upstream commit 7ceb40027e19567a0a066e3b380cc034cdd9a124 ]

    The verification and message introduced by commit 374f3f5979f9
    ("powerpc/mm/hash: Handle user access of kernel address gracefully")
    applies to all platforms, it should not be limited to BOOK3S.

    Make the BOOK3S version of sanity_check_fault() the one for all,
    and bail out earlier if not BOOK3S.

    Fixes: 374f3f5979f9 ("powerpc/mm/hash: Handle user access of kernel address gracefully")
    Signed-off-by: Christophe Leroy
    Reviewed-by: Nicholas Piggin
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/fe199d5af3578d3bf80035d203a94d742a7a28af.1607491748.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin

    Christophe Leroy
     
  • [ Upstream commit db972a3787d12b1ce9ba7a31ec376d8a79e04c47 ]

    low_sleep_handler() can't restore the context from standard
    stack because the stack can hardly be accessed with MMU OFF.

    Store everything in a global storage area instead of storing
    a pointer to the stack in that global storage area.

    To avoid a complete churn of the function, still use r1 as
    the pointer to the storage area during restore.

    Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK")
    Reported-by: Giuseppe Sacco
    Signed-off-by: Christophe Leroy
    Tested-by: Giuseppe Sacco
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin

    Christophe Leroy
     
  • [ Upstream commit b866459489fe8ef0e92cde3cbd6bbb1af6c4e99b ]

    Partitions with cache nodes in the device tree can encounter the
    following warning on resume:

    CPU 0 already accounted in PowerPC,POWER9@0(Data)
    WARNING: CPU: 0 PID: 3177 at arch/powerpc/kernel/cacheinfo.c:197 cacheinfo_cpu_online+0x640/0x820

    These calls to cacheinfo_cpu_offline/online have been redundant since
    commit e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo
    hierarchy post-migration").

    Fixes: e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration")
    Signed-off-by: Nathan Lynch
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201207215200.1785968-25-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin

    Nathan Lynch
     
  • [ Upstream commit 52719fce3f4c7a8ac9eaa191e8d75a697f9fbcbc ]

    There are three ways pseries_suspend_begin() can be reached:

    1. When "mem" is written to /sys/power/state:

    kobj_attr_store()
    -> state_store()
    -> pm_suspend()
    -> suspend_devices_and_enter()
    -> pseries_suspend_begin()

    This never works because there is no way to supply a valid stream id
    using this interface, and H_VASI_STATE is called with a stream id of
    zero. So this call path is useless at best.

    2. When a stream id is written to /sys/devices/system/power/hibernate.
    pseries_suspend_begin() is polled directly from store_hibernate()
    until the stream is in the "Suspending" state (i.e. the platform is
    ready for the OS to suspend execution):

    dev_attr_store()
    -> store_hibernate()
    -> pseries_suspend_begin()

    3. When a stream id is written to /sys/devices/system/power/hibernate
    (continued). After #2, pseries_suspend_begin() is called once again
    from the pm core:

    dev_attr_store()
    -> store_hibernate()
    -> pm_suspend()
    -> suspend_devices_and_enter()
    -> pseries_suspend_begin()

    This is redundant because the VASI suspend state is already known to
    be Suspending.

    The begin() callback of platform_suspend_ops is optional, so we can
    simply remove that assignment with no loss of function.

    Fixes: 32d8ad4e621d ("powerpc/pseries: Partition hibernation support")
    Signed-off-by: Nathan Lynch
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201207215200.1785968-18-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin

    Nathan Lynch
     
  • [ Upstream commit 0263bbb377af0c2d38bc8b2ad2ff147e240094de ]

    The PMU group constraints mask for threshold events covers
    all thresholding bits which includes threshold control value
    (start/stop), select value as well as thresh_cmp value (MMCRA[9:18].
    In power9, thresh_cmp bits were part of the event code. But in case
    of power10, thresh_cmp bits are not part of event code due to
    inclusion of MMCR3 bits. Hence thresh_cmp is not valid for
    group constraints for power10.

    Fix the PMU group constraints checking for threshold events in
    power10 by using constraint mask and value for only threshold control
    and select bits.

    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1606409684-1589-4-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin

    Athira Rajeev
     
  • [ Upstream commit e924be7b0b0d1f37d0509c854a92c7a71e3cdfe7 ]

    In Power9, L2/L3 bus events are always available as a
    "bank" of 4 events. To obtain the counts for any of the
    l2/l3 bus events in a given bank, the user will have to
    program PMC4 with corresponding l2/l3 bus event for that
    bank.

    Commit 59029136d750 ("powerpc/perf: Add constraints for power9 l2/l3 bus events")
    enforced this rule in Power9. But this is not valid for
    Power10, since in Power10 Monitor Mode Control Register2
    (MMCR2) has bits to configure l2/l3 event bits. Hence remove
    this PMC4 constraint check from power10.

    Since the l2/l3 bits in MMCR2 are not per-pmc, patch handles
    group constrints checks for l2/l3 bits in MMCR2.

    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1606409684-1589-3-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin

    Athira Rajeev
     
  • [ Upstream commit d3afd28cd2f35b2a1046b76e0cf010b684da2e84 ]

    power10 uses bit 9 of the raw event code as RADIX_SCOPE_QUAL.
    This bit is used for enabling the radix process events.
    Patch fixes the PMU counter support functions to program bit
    18 of MMCR1 ( Monitor Mode Control Register1 ) with the
    RADIX_SCOPE_QUAL bit value. Since this field is not per-pmc,
    add this to PMU group constraints to make sure events in a
    group will have same bit value for this field. Use bit 21 as
    constraint bit field for radix_scope_qual. Patch also updates
    the power10 raw event encoding layout information, format field
    and constraints bit layout to include the radix_scope_qual bit.

    Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support")
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1606409684-1589-2-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin

    Athira Rajeev
     
  • [ Upstream commit f3e90408019b353fd1fcd338091fb8d3c4a1c1a5 ]

    With CONFIG_PPC_8xx and CONFIG_XMON set, kernel build fails with

    arch/powerpc/xmon/xmon.c:1379:12: error: 'find_free_data_bpt' defined
    but not used [-Werror=unused-function]

    Fix it by enclosing find_free_data_bpt() inside #ifndef CONFIG_PPC_8xx.

    Fixes: 30df74d67d48 ("powerpc/watchpoint/xmon: Support 2nd DAWR")
    Reported-by: kernel test robot
    Signed-off-by: Ravi Bangoria
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201130034406.288047-1-ravi.bangoria@linux.ibm.com
    Signed-off-by: Sasha Levin

    Ravi Bangoria
     
  • [ Upstream commit fe18a35e685c9bdabc8b11b3e19deb85a068b75d ]

    Commit 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard
    trap") added an EMIT_BUG_ENTRY for the trap after the branch to
    start_kernel(). The EMIT_BUG_ENTRY was for the address "0b", however the
    trap was not labeled with "0". Hence the address used for bug is in
    relative_toc() where the previous "0" label is. Label the trap as "0" so
    the correct address is used.

    Fixes: 63ce271b5e37 ("powerpc/prom: convert PROM_BUG() to standard trap")
    Signed-off-by: Jordan Niethe
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201130004404.30953-1-jniethe5@gmail.com
    Signed-off-by: Sasha Levin

    Jordan Niethe
     
  • [ Upstream commit f75e7d73bdf73f07b0701a6d21c111ef5d9021dd ]

    On systems without any specific PMU driver support registered, running
    'perf record' with —intr-regs will crash ( perf record -I ).

    The relevant portion from crash logs and Call Trace:

    Unable to handle kernel paging request for data at address 0x00000068
    Faulting instruction address: 0xc00000000013eb18
    Oops: Kernel access of bad area, sig: 11 [#1]
    CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
    NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
    REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
    NIP [c00000000013eb18] is_sier_available+0x18/0x30
    LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
    Call Trace:
    [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
    [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
    [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
    [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
    [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
    [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
    [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
    [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
    [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120

    When perf record session is started with "-I" option, capturing registers
    on each sample calls is_sier_available() to check for the
    SIER (Sample Instruction Event Register) availability in the platform.
    This function in core-book3s accesses 'ppmu->flags'. If a platform specific
    PMU driver is not registered, ppmu is set to NULL and accessing its
    members results in a crash. Fix the crash by returning false in
    is_sier_available() if ppmu is not set.

    Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
    Reported-by: Sachin Sant
    Signed-off-by: Athira Rajeev
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1606185640-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com
    Signed-off-by: Sasha Levin

    Athira Rajeev
     
  • [ Upstream commit 027717a45ca251a7ba67a63db359994836962cd2 ]

    Fix coccicheck warning:

    arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10:
    WARNING: Unsigned expression compared with zero: win < 0

    arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10:
    WARNING: Unsigned expression compared with zero: win < 0

    Fixes: 39efc03e3ee8 ("powerpc/powernv/sriov: Move M64 BAR allocation into a helper")
    Reported-by: Tosk Robot
    Signed-off-by: Kaixu Xia
    Reviewed-by: Andrew Donnellan
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/1605007170-22171-1-git-send-email-kaixuxia@tencent.com
    Signed-off-by: Sasha Levin

    Kaixu Xia
     
  • [ Upstream commit a40fdaf1420d6e6bda0dd2df1e6806013e58dbe1 ]

    This reverts commit a0ff72f9f5a780341e7ff5e9ba50a0dad5fa1980.

    Since the commit b015f6bc9547 ("powerpc/pseries: Add cpu DLPAR
    support for drc-info property"), the 'cpu_drcs' wouldn't be double
    freed when the 'cpus' node not found.

    So we needn't apply this patch, otherwise, the memory will be leaked.

    Fixes: a0ff72f9f5a7 ("powerpc/pseries/hotplug-cpu: Remove double free in error path")
    Reported-by: Hulk Robot
    Signed-off-by: Zhang Xiaoxu
    [mpe: Caused by me applying a patch to a function that had changed in the interim]
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/20201111020752.1686139-1-zhangxiaoxu5@huawei.com
    Signed-off-by: Sasha Levin

    Zhang Xiaoxu
     
  • [ Upstream commit 78665179e569c7e1fe102fb6c21d0f5b6951f084 ]

    On 8xx, we get the following features:

    [ 0.000000] cpu_features = 0x0000000000000100
    [ 0.000000] possible = 0x0000000000000120
    [ 0.000000] always = 0x0000000000000000

    This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all
    other configurations, the three lines should be equal.

    The problem is due to CPU_FTRS_GENERIC_32 which is taken when
    CONFIG_BOOK3S_32 is NOT selected. This CPU_FTRS_GENERIC_32 is
    pointless because there is no generic configuration supporting
    all 32 bits but book3s/32.

    Remove this pointless generic features definition to unbreak the
    calculation of 'possible' features and 'always' features.

    Fixes: 76bc080ef5a3 ("[POWERPC] Make default cputable entries reflect selected CPU family")
    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Link: https://lore.kernel.org/r/76a85f30bf981d1aeaae00df99321235494da254.1604426550.git.christophe.leroy@csgroup.eu
    Signed-off-by: Sasha Levin

    Christophe Leroy