1. 19 Oct, 2023 14 commits
  2. 18 Oct, 2023 3 commits
  3. 17 Oct, 2023 1 commit
    • Michael Ellerman's avatar
      powerpc/64s/radix: Don't warn on copros in radix__tlb_flush() · 20045f01
      Michael Ellerman authored
      Sachin reported a warning when running the inject-ra-err selftest:
      
        # selftests: powerpc/mce: inject-ra-err
        Disabling lock debugging due to kernel taint
        MCE: CPU19: machine check (Severe)  Real address Load/Store (foreign/control memory) [Not recovered]
        MCE: CPU19: PID: 5254 Comm: inject-ra-err NIP: [0000000010000e48]
        MCE: CPU19: Initiator CPU
        MCE: CPU19: Unknown
        ------------[ cut here ]------------
        WARNING: CPU: 19 PID: 5254 at arch/powerpc/mm/book3s64/radix_tlb.c:1221 radix__tlb_flush+0x160/0x180
        CPU: 19 PID: 5254 Comm: inject-ra-err Kdump: loaded Tainted: G   M        E      6.6.0-rc3-00055-g9ed22ae6 #4
        Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1030.20 (NH1030_058) hv:phyp pSeries
        ...
        NIP radix__tlb_flush+0x160/0x180
        LR  radix__tlb_flush+0x104/0x180
        Call Trace:
          radix__tlb_flush+0xf4/0x180 (unreliable)
          tlb_finish_mmu+0x15c/0x1e0
          exit_mmap+0x1a0/0x510
          __mmput+0x60/0x1e0
          exit_mm+0xdc/0x170
          do_exit+0x2bc/0x5a0
          do_group_exit+0x4c/0xc0
          sys_exit_group+0x28/0x30
          system_call_exception+0x138/0x330
          system_call_vectored_common+0x15c/0x2ec
      
      And bisected it to commit e43c0a0c ("powerpc/64s/radix: combine
      final TLB flush and lazy tlb mm shootdown IPIs"), which added a warning
      in radix__tlb_flush() if mm->context.copros is still elevated.
      
      However it's possible for the copros count to be elevated if a process
      exits without first closing file descriptors that are associated with a
      copro, eg. VAS.
      
      If the process exits with a VAS file still open, the release callback
      is queued up for exit_task_work() via:
        exit_files()
          put_files_struct()
            close_files()
              filp_close()
                fput()
      
      And called via:
        exit_task_work()
          ____fput()
            __fput()
              file->f_op->release(inode, file)
                coproc_release()
                  vas_user_win_ops->close_win()
                    vas_deallocate_window()
                      mm_context_remove_vas_window()
                        mm_context_remove_copro()
      
      But that is after exit_mm() has been called from do_exit() and triggered
      the warning.
      
      Fix it by dropping the warning, and always calling __flush_all_mm().
      
      In the normal case of no copros, that will result in a call to
      _tlbiel_pid(mm->context.id, RIC_FLUSH_ALL) just as the current code
      does.
      
      If the copros count is elevated then it will cause a global flush, which
      should flush translations from any copros. Note that the process table
      entry was cleared in arch_exit_mmap(), so copros should not be able to
      fetch any new translations.
      
      Fixes: e43c0a0c ("powerpc/64s/radix: combine final TLB flush and lazy tlb mm shootdown IPIs")
      Reported-by: default avatarSachin Sant <sachinp@linux.ibm.com>
      Closes: https://lore.kernel.org/all/A8E52547-4BF1-47CE-8AEA-BC5A9D7E3567@linux.ibm.com/Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Tested-by: default avatarSachin Sant <sachinp@linux.ibm.com>
      Link: https://msgid.link/20231017121527.1574104-1-mpe@ellerman.id.au
      20045f01
  4. 15 Oct, 2023 1 commit
  5. 10 Oct, 2023 3 commits
  6. 09 Oct, 2023 2 commits
  7. 01 Oct, 2023 1 commit
    • Dr. David Alan Gilbert's avatar
      powerpc: Use shared font data · 0ebc7fea
      Dr. David Alan Gilbert authored
      PowerPC has a 'btext' font used for the console which is almost identical
      to the shared font_sun8x16, so use it rather than duplicating the data.
      
      They were actually identical until about a decade ago when
         commit bcfbeece ("drivers: console: font_: Change a glyph from
                              "broken bar" to "vertical line"")
      
      which changed the | in the shared font to be a solid
      bar rather than a broken bar.  That's the only difference.
      
      This was originally spotted by the PMF source code analyser, which
      noticed that sparc does the same thing with the same data, and they
      also share a bunch of functions to manipulate the data.  I've previously
      posted a near identical patch for sparc.
      
      Tested very lightly with a boot without FS in qemu.
      Signed-off-by: default avatar"Dr. David Alan Gilbert" <linux@treblig.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230825142754.1487900-1-linux@treblig.org
      0ebc7fea
  8. 30 Sep, 2023 2 commits
    • Athira Rajeev's avatar
      powerpc/pseries: Remove unused r0 in the hcall tracing code · dfb5f8cb
      Athira Rajeev authored
      In the plpar_hcall trace code, currently we use r0
      to store the value of r4. But this value is not
      used subsequently in the code. Hence remove this unused
      save to r0 in plpar_hcall and plpar_hcall9
      Suggested-by: default avatarNaveen N Rao <naveen@kernel.org>
      Signed-off-by: default avatarAthira Rajeev <atrajeev@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230929172337.7906-2-atrajeev@linux.vnet.ibm.com
      dfb5f8cb
    • Athira Rajeev's avatar
      powerpc/pseries: Fix STK_PARAM access in the hcall tracing code · 3b678768
      Athira Rajeev authored
      In powerpc pseries system, below behaviour is observed while
      enabling tracing on hcall:
        # cd /sys/kernel/debug/tracing/
        # cat events/powerpc/hcall_exit/enable
        0
        # echo 1 > events/powerpc/hcall_exit/enable
      
        # ls
        -bash: fork: Bad address
      
      Above is from power9 lpar with latest kernel. Past this, softlockup
      is observed. Initially while attempting via perf_event_open to
      use "PERF_TYPE_TRACEPOINT", kernel panic was observed.
      
      perf config used:
      ================
        memset(&pe[1],0,sizeof(struct perf_event_attr));
        pe[1].type=PERF_TYPE_TRACEPOINT;
        pe[1].size=96;
        pe[1].config=0x26ULL; /* 38 raw_syscalls/sys_exit */
        pe[1].sample_type=0; /* 0 */
        pe[1].read_format=PERF_FORMAT_TOTAL_TIME_ENABLED|PERF_FORMAT_TOTAL_TIME_RUNNING|PERF_FORMAT_ID|PERF_FORMAT_GROUP|0x10ULL; /* 1f */
        pe[1].inherit=1;
        pe[1].precise_ip=0; /* arbitrary skid */
        pe[1].wakeup_events=0;
        pe[1].bp_type=HW_BREAKPOINT_EMPTY;
        pe[1].config1=0x1ULL;
      
      Kernel panic logs:
      ==================
      
        Kernel attempted to read user page (8) - exploit attempt? (uid: 0)
        BUG: Kernel NULL pointer dereference on read at 0x00000008
        Faulting instruction address: 0xc0000000004c2814
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: nfnetlink bonding tls rfkill sunrpc dm_service_time dm_multipath pseries_rng xts vmx_crypto xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ibmvfc scsi_transport_fc ibmveth dm_mirror dm_region_hash dm_log dm_mod fuse
        CPU: 0 PID: 1431 Comm: login Not tainted 6.4.0+ #1
        Hardware name: IBM,8375-42A POWER9 (raw) 0x4e0202 0xf000005 of:IBM,FW950.30 (VL950_892) hv:phyp pSeries
        NIP page_remove_rmap+0x44/0x320
        LR  wp_page_copy+0x384/0xec0
        Call Trace:
          0xc00000001416e400 (unreliable)
          wp_page_copy+0x384/0xec0
          __handle_mm_fault+0x9d4/0xfb0
          handle_mm_fault+0xf0/0x350
          ___do_page_fault+0x48c/0xc90
          hash__do_page_fault+0x30/0x70
          do_hash_fault+0x1a4/0x330
          data_access_common_virt+0x198/0x1f0
         --- interrupt: 300 at 0x7fffae971abc
      
      git bisect tracked this down to below commit:
      'commit baa49d81 ("powerpc/pseries: hvcall stack frame overhead")'
      
      This commit changed STACK_FRAME_OVERHEAD (112 ) to
      STACK_FRAME_MIN_SIZE (32 ) since 32 bytes is the minimum size
      for ELFv2 stack. With the latest kernel, when running on ELFv2,
      STACK_FRAME_MIN_SIZE is used to allocate stack size.
      
      During plpar_hcall_trace, first call is made to HCALL_INST_PRECALL
      which saves the registers and allocates new stack frame. In the
      plpar_hcall_trace code, STK_PARAM is accessed at two places.
        1. To save r4: std     r4,STK_PARAM(R4)(r1)
        2. To access r4 back: ld      r12,STK_PARAM(R4)(r1)
      
      HCALL_INST_PRECALL precall allocates a new stack frame. So all
      the stack parameter access after the precall, needs to be accessed
      with +STACK_FRAME_MIN_SIZE. So the store instruction should be:
        std     r4,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
      
      If the "std" is not updated with STACK_FRAME_MIN_SIZE, we will
      end up with overwriting stack contents and cause corruption.
      But instead of updating 'std', we can instead remove it since
      HCALL_INST_PRECALL already saves it to the correct location.
      
      similarly load instruction should be:
        ld      r12,STACK_FRAME_MIN_SIZE+STK_PARAM(R4)(r1)
      
      Fix the load instruction to correctly access the stack parameter
      with +STACK_FRAME_MIN_SIZE and remove the store of r4 since the
      precall saves it correctly.
      
      Cc: stable@vger.kernel.org # v6.2+
      Fixes: baa49d81 ("powerpc/pseries: hvcall stack frame overhead")
      Co-developed-by: default avatarNaveen N Rao <naveen@kernel.org>
      Signed-off-by: default avatarNaveen N Rao <naveen@kernel.org>
      Signed-off-by: default avatarAthira Rajeev <atrajeev@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20230929172337.7906-1-atrajeev@linux.vnet.ibm.com
      3b678768
  9. 22 Sep, 2023 2 commits
  10. 19 Sep, 2023 2 commits
  11. 18 Sep, 2023 9 commits