1. 22 Oct, 2020 2 commits
    • Ganesh Goudar's avatar
      powerpc/pseries: Avoid using addr_to_pfn in real mode · 4ff753fe
      Ganesh Goudar authored
      When an UE or memory error exception is encountered the MCE handler
      tries to find the pfn using addr_to_pfn() which takes effective
      address as an argument, later pfn is used to poison the page where
      memory error occurred, recent rework in this area made addr_to_pfn
      to run in real mode, which can be fatal as it may try to access
      memory outside RMO region.
      
      Have two helper functions to separate things to be done in real mode
      and virtual mode without changing any functionality. This also fixes
      the following error as the use of addr_to_pfn is now moved to virtual
      mode.
      
      Without this change following kernel crash is seen on hitting UE.
      
      [  485.128036] Oops: Kernel access of bad area, sig: 11 [#1]
      [  485.128040] LE SMP NR_CPUS=2048 NUMA pSeries
      [  485.128047] Modules linked in:
      [  485.128067] CPU: 15 PID: 6536 Comm: insmod Kdump: loaded Tainted: G OE 5.7.0 #22
      [  485.128074] NIP:  c00000000009b24c LR: c0000000000398d8 CTR: c000000000cd57c0
      [  485.128078] REGS: c000000003f1f970 TRAP: 0300   Tainted: G OE (5.7.0)
      [  485.128082] MSR:  8000000000001003 <SF,ME,RI,LE>  CR: 28008284  XER: 00000001
      [  485.128088] CFAR: c00000000009b190 DAR: c0000001fab00000 DSISR: 40000000 IRQMASK: 1
      [  485.128088] GPR00: 0000000000000001 c000000003f1fbf0 c000000001634300 0000b0fa01000000
      [  485.128088] GPR04: d000000002220000 0000000000000000 00000000fab00000 0000000000000022
      [  485.128088] GPR08: c0000001fab00000 0000000000000000 c0000001fab00000 c000000003f1fc14
      [  485.128088] GPR12: 0000000000000008 c000000003ff5880 d000000002100008 0000000000000000
      [  485.128088] GPR16: 000000000000ff20 000000000000fff1 000000000000fff2 d0000000021a1100
      [  485.128088] GPR20: d000000002200000 c00000015c893c50 c000000000d49b28 c00000015c893c50
      [  485.128088] GPR24: d0000000021a0d08 c0000000014e5da8 d0000000021a0818 000000000000000a
      [  485.128088] GPR28: 0000000000000008 000000000000000a c0000000017e2970 000000000000000a
      [  485.128125] NIP [c00000000009b24c] __find_linux_pte+0x11c/0x310
      [  485.128130] LR [c0000000000398d8] addr_to_pfn+0x138/0x170
      [  485.128133] Call Trace:
      [  485.128135] Instruction dump:
      [  485.128138] 3929ffff 7d4a3378 7c883c36 7d2907b4 794a1564 7d294038 794af082 3900ffff
      [  485.128144] 79291f24 790af00e 78e70020 7d095214 <7c69502a> 2fa30000 419e011c 70690040
      [  485.128152] ---[ end trace d34b27e29ae0e340 ]---
      
      Fixes: 9ca766f9 ("powerpc/64s/pseries: machine check convert to use common event code")
      Signed-off-by: default avatarGanesh Goudar <ganeshgr@linux.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200724063946.21378-1-ganeshgr@linux.ibm.com
      4ff753fe
    • Christophe Leroy's avatar
      powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9 · 592bbe9c
      Christophe Leroy authored
      GCC 4.9 sometimes fails to build with "m<>" constraint in
      inline assembly.
      
        CC      lib/iov_iter.o
      In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
                       from ./arch/powerpc/include/asm/atomic.h:11,
                       from ./include/linux/atomic.h:7,
                       from ./include/linux/crypto.h:15,
                       from ./include/crypto/hash.h:11,
                       from lib/iov_iter.c:2:
      lib/iov_iter.c: In function 'iovec_from_user.part.30':
      ./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has impossible constraints
        __asm__ __volatile__(    \
        ^
      ./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
       # define unlikely(x) __builtin_expect(!!(x), 0)
                                                ^
      ./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro 'unsafe_op_wrap'
       #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
                                        ^
      ./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro '__get_user_asm'
        case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
                ^
      ./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro '__get_user_size_allowed'
         __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
         ^
      ./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro '__get_user_nocheck'
        __get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
        ^
      ./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro '__get_user_allowed'
       #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
                                                       ^
      lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
         unsafe_get_user(len, &uiov[i].iov_len, uaccess_end);
         ^
      make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
      
      Define a UPD_CONSTR macro that is "<>" by default and
      only "" with GCC prior to GCC 5.
      
      Fixes: fcf1f268 ("powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()")
      Fixes: 2f279eeb ("powerpc/uaccess: Add pre-update addressing to __get_user_asm() and __put_user_asm()")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@csgroup.eu>
      Acked-by: default avatarSegher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/212d3bc4a52ca71523759517bb9c61f7e477c46a.1603179582.git.christophe.leroy@csgroup.eu
      592bbe9c
  2. 21 Oct, 2020 1 commit
    • Oliver O'Halloran's avatar
      powerpc/eeh: Fix eeh_dev_check_failure() for PE#0 · 99f6e979
      Oliver O'Halloran authored
      In commit 269e5833 ("powerpc/eeh: Delete eeh_pe->config_addr") the
      following simplification was made:
      
      -       if (!pe->addr && !pe->config_addr) {
      +       if (!pe->addr) {
                      eeh_stats.no_cfg_addr++;
                      return 0;
              }
      
      This introduced a bug which causes EEH checking to be skipped for
      devices in PE#0.
      
      Before the change above the check would always pass since at least one
      of the two PE addresses would be non-zero in all circumstances. On
      PowerNV pe->config_addr would be the BDFN of the first device added to
      the PE. The zero BDFN is reserved for the PHB's root port, but this is
      fine since for obscure platform reasons the root port is never
      assigned to PE#0.
      
      Similarly, on pseries pe->addr has always been non-zero for the
      reasons outlined in commit 42de19d5 ("powerpc/pseries/eeh: Allow
      zero to be a valid PE configuration address").
      
      We can fix the problem by deleting the block entirely The original
      purpose of this test was to avoid performing EEH checks on devices
      that were not on an EEH capable bus. In modern Linux the edev->pe
      pointer will be NULL for devices that are not on an EEH capable bus.
      The code block immediately above this one already checks for the
      edev->pe == NULL case so this test (new and old) is entirely
      redundant.
      
      Ideally we'd delete eeh_stats.no_cfg_addr too since nothing increments
      it any more. Unfortunately, that information is exposed via
      /proc/powerpc/eeh which means it's technically ABI. We could make it
      hard-coded, but that's a change for another patch.
      
      Fixes: 269e5833 ("powerpc/eeh: Delete eeh_pe->config_addr")
      Signed-off-by: default avatarOliver O'Halloran <oohall@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201021232554.1434687-1-oohall@gmail.com
      99f6e979
  3. 20 Oct, 2020 1 commit
  4. 19 Oct, 2020 6 commits
    • Michael Neuling's avatar
      selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load workaround · d1781f23
      Michael Neuling authored
      alignment_handler currently only tests the unaligned cases but it can
      also be useful for testing the workaround for the P9N DD2.1 vector CI
      load issue fixed by p9_hmi_special_emu(). This workaround was
      introduced in 5080332c ("powerpc/64s: Add workaround for P9 vector
      CI load issue").
      
      This changes the loop to start from offset 0 rather than 1 so that we
      test the kernel emulation in p9_hmi_special_emu().
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201013043741.743413-2-mikey@neuling.org
      d1781f23
    • Michael Neuling's avatar
      powerpc: Fix undetected data corruption with P9N DD2.1 VSX CI load emulation · 1da4a027
      Michael Neuling authored
      __get_user_atomic_128_aligned() stores to kaddr using stvx which is a
      VMX store instruction, hence kaddr must be 16 byte aligned otherwise
      the store won't occur as expected.
      
      Unfortunately when we call __get_user_atomic_128_aligned() in
      p9_hmi_special_emu(), the buffer we pass as kaddr (ie. vbuf) isn't
      guaranteed to be 16B aligned. This means that the write to vbuf in
      __get_user_atomic_128_aligned() has the bottom bits of the address
      truncated. This results in other local variables being
      overwritten. Also vbuf will not contain the correct data which results
      in the userspace emulation being wrong and hence undetected user data
      corruption.
      
      In the past we've been mostly lucky as vbuf has ended up aligned but
      this is fragile and isn't always true. CONFIG_STACKPROTECTOR in
      particular can change the stack arrangement enough that our luck runs
      out.
      
      This issue only occurs on POWER9 Nimbus <= DD2.1 bare metal.
      
      The fix is to align vbuf to a 16 byte boundary.
      
      Fixes: 5080332c ("powerpc/64s: Add workaround for P9 vector CI load issue")
      Cc: stable@vger.kernel.org # v4.15+
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201013043741.743413-1-mikey@neuling.org
      1da4a027
    • Vasant Hegde's avatar
      powerpc/powernv/dump: Handle multiple writes to ack attribute · 358ab796
      Vasant Hegde authored
      Even though we use self removing sysfs helper, we still need
      to make sure we do the final kobject delete conditionally.
      sysfs_remove_file_self() will handle parallel calls to remove
      the sysfs attribute file and returns true only in the caller
      that removed the attribute file. The other parallel callers
      are returned false. Do the final kobject delete checking
      the return value of sysfs_remove_file_self().
      Signed-off-by: default avatarVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201017164236.264713-1-hegdevasant@linux.vnet.ibm.com
      358ab796
    • Vasant Hegde's avatar
      powerpc/powernv/dump: Fix race while processing OPAL dump · 0a43ae3e
      Vasant Hegde authored
      Every dump reported by OPAL is exported to userspace through a sysfs
      interface and notified using kobject_uevent(). The userspace daemon
      (opal_errd) then reads the dump and acknowledges that the dump is
      saved safely to disk. Once acknowledged the kernel removes the
      respective sysfs file entry causing respective resources to be
      released including kobject.
      
      However it's possible the userspace daemon may already be scanning
      dump entries when a new sysfs dump entry is created by the kernel.
      User daemon may read this new entry and ack it even before kernel can
      notify userspace about it through kobject_uevent() call. If that
      happens then we have a potential race between
      dump_ack_store->kobject_put() and kobject_uevent which can lead to
      use-after-free of a kernfs object resulting in a kernel crash.
      
      This patch fixes this race by protecting the sysfs file
      creation/notification by holding a reference count on kobject until we
      safely send kobject_uevent().
      
      The function create_dump_obj() returns the dump object which if used
      by caller function will end up in use-after-free problem again.
      However, the return value of create_dump_obj() function isn't being
      used today and there is no need as well. Hence change it to return
      void to make this fix complete.
      
      Fixes: c7e64b9c ("powerpc/powernv Platform dump interface")
      Signed-off-by: default avatarVasant Hegde <hegdevasant@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201017164210.264619-1-hegdevasant@linux.vnet.ibm.com
      0a43ae3e
    • Srikar Dronamraju's avatar
      powerpc/smp: Use GFP_ATOMIC while allocating tmp mask · 84dbf66c
      Srikar Dronamraju authored
      Qian Cai reported a regression where CPU Hotplug fails with the latest
      powerpc/next
      
      BUG: sleeping function called from invalid context at mm/slab.h:494
      in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/88
      no locks held by swapper/88/0.
      irq event stamp: 18074448
      hardirqs last  enabled at (18074447): [<c0000000001a2a7c>] tick_nohz_idle_enter+0x9c/0x110
      hardirqs last disabled at (18074448): [<c000000000106798>] do_idle+0x138/0x3b0
      do_idle at kernel/sched/idle.c:253 (discriminator 1)
      softirqs last  enabled at (18074440): [<c0000000000bbec4>] irq_enter_rcu+0x94/0xa0
      softirqs last disabled at (18074439): [<c0000000000bbea0>] irq_enter_rcu+0x70/0xa0
      CPU: 88 PID: 0 Comm: swapper/88 Tainted: G        W         5.9.0-rc8-next-20201007 #1
      Call Trace:
      [c00020000a4bfcf0] [c000000000649e98] dump_stack+0xec/0x144 (unreliable)
      [c00020000a4bfd30] [c0000000000f6c34] ___might_sleep+0x2f4/0x310
      [c00020000a4bfdb0] [c000000000354f94] slab_pre_alloc_hook.constprop.82+0x124/0x190
      [c00020000a4bfe00] [c00000000035e9e8] __kmalloc_node+0x88/0x3a0
      slab_alloc_node at mm/slub.c:2817
      (inlined by) __kmalloc_node at mm/slub.c:4013
      [c00020000a4bfe80] [c0000000006494d8] alloc_cpumask_var_node+0x38/0x80
      kmalloc_node at include/linux/slab.h:577
      (inlined by) alloc_cpumask_var_node at lib/cpumask.c:116
      [c00020000a4bfef0] [c00000000003eedc] start_secondary+0x27c/0x800
      update_mask_by_l2 at arch/powerpc/kernel/smp.c:1267
      (inlined by) add_cpu_to_masks at arch/powerpc/kernel/smp.c:1387
      (inlined by) start_secondary at arch/powerpc/kernel/smp.c:1420
      [c00020000a4bff90] [c00000000000c468] start_secondary_resume+0x10/0x14
      
      Allocating a temporary mask while performing a CPU Hotplug operation
      with CONFIG_CPUMASK_OFFSTACK enabled, leads to calling a sleepable
      function from a atomic context. Fix this by allocating the temporary
      mask with GFP_ATOMIC flag. Also instead of having to allocate twice,
      allocate the mask in the caller so that we only have to allocate once.
      If the allocation fails, assume the mask to be same as sibling mask, which
      will make the scheduler to drop this domain for this CPU.
      
      Fixes: 70a94089 ("powerpc/smp: Optimize update_coregroup_mask")
      Fixes: 3ab33d6d ("powerpc/smp: Optimize update_mask_by_l2")
      Reported-by: default avatarQian Cai <cai@redhat.com>
      Signed-off-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201019042716.106234-3-srikar@linux.vnet.ibm.com
      84dbf66c
    • Srikar Dronamraju's avatar
      powerpc/smp: Remove unnecessary variable · 966730a6
      Srikar Dronamraju authored
      Commit 3ab33d6d ("powerpc/smp: Optimize update_mask_by_l2")
      introduced submask_fn in update_mask_by_l2 to track the right submask.
      However commit f6606cfd ("powerpc/smp: Dont assume l2-cache to be
      superset of sibling") introduced sibling_mask in update_mask_by_l2 to
      track the same submask. Remove sibling_mask in favour of submask_fn.
      Signed-off-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201019042716.106234-2-srikar@linux.vnet.ibm.com
      966730a6
  5. 16 Oct, 2020 2 commits
  6. 15 Oct, 2020 1 commit
    • Qian Cai's avatar
      Revert "powerpc/pci: unmap legacy INTx interrupts when a PHB is removed" · ffd0b25c
      Qian Cai authored
      This reverts commit 3a3181e1 which
      causes memory corruptions on POWER9 powernv. eg:
      
        pci_bus 0035:08: busn_res: [bus 08-0c] is released
        =============================================================================
        BUG kmalloc-16 (Tainted: G        W  O     ): Object already free
        -----------------------------------------------------------------------------
        Disabling lock debugging due to kernel taint
        INFO: Allocated in pcibios_scan_phb+0x104/0x3e0 age=1960714 cpu=4 pid=1
        	__slab_alloc+0xa4/0xf0
        	__kmalloc+0x294/0x330
        	pcibios_scan_phb+0x104/0x3e0
        	pcibios_init+0x84/0x124
        	do_one_initcall+0xac/0x528
        	kernel_init_freeable+0x35c/0x3fc
        	kernel_init+0x24/0x148
        	ret_from_kernel_thread+0x5c/0x80
        INFO: Freed in pcibios_remove_bus+0x70/0x90 age=0 cpu=16 pid=1717146
        	kfree+0x49c/0x510
        	pcibios_remove_bus+0x70/0x90
        	pci_remove_bus+0xe4/0x110
        	pci_remove_bus_device+0x74/0x170
        	pci_remove_bus_device+0x4c/0x170
        	pci_stop_and_remove_bus_device_locked+0x34/0x50
        	remove_store+0xc0/0xe0
        	dev_attr_store+0x30/0x50
        	sysfs_kf_write+0x68/0xb0
        	kernfs_fop_write+0x114/0x260
        	vfs_write+0xe4/0x260
        	ksys_write+0x74/0x130
        	system_call_exception+0xf8/0x1d0
        	system_call_common+0xe8/0x218
        INFO: Slab 0x0000000099caaf22 objects=178 used=174 fp=0x00000000006a64b0 flags=0x7fff8000000201
        INFO: Object 0x00000000f360132d @offset=30192 fp=0x0000000000000000
      Signed-off-by: default avatarQian Cai <cai@lca.pw>
      Acked-by: default avatarOliver O'Halloran <oohall@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20201014182811.12027-1-cai@lca.pw
      ffd0b25c
  7. 14 Oct, 2020 1 commit
  8. 08 Oct, 2020 25 commits
  9. 07 Oct, 2020 1 commit