1. 05 Feb, 2024 3 commits
    • Naveen N Rao's avatar
      powerpc/64: Set task pt_regs->link to the LR value on scv entry · aad98efd
      Naveen N Rao authored
      Nysal reported that userspace backtraces are missing in offcputime bcc
      tool. As an example:
          $ sudo ./bcc/tools/offcputime.py -uU
          Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
      
          ^C
      	write
      	-                python (9107)
      	    8
      
      	write
      	-                sudo (9105)
      	    9
      
      	mmap
      	-                python (9107)
      	    16
      
      	clock_nanosleep
      	-                multipathd (697)
      	    3001604
      
      The offcputime bcc tool attaches a bpf program to a kprobe on
      finish_task_switch(), which is usually hit on a syscall from userspace.
      With the switch to system call vectored, we started setting
      pt_regs->link to zero. This is because system call vectored behaves like
      a function call with LR pointing to the system call return address, and
      with no modification to SRR0/SRR1. The LR value does indicate our next
      instruction, so it is being saved as pt_regs->nip, and pt_regs->link is
      being set to zero. This is not a problem by itself, but BPF uses perf
      callchain infrastructure for capturing stack traces, and that stores LR
      as the second entry in the stack trace. perf has code to cope with the
      second entry being zero, and skips over it. However, generic userspace
      unwinders assume that a zero entry indicates end of the stack trace,
      resulting in a truncated userspace stack trace.
      
      Rather than fixing all userspace unwinders to ignore/skip past the
      second entry, store the real LR value in pt_regs->link so that there
      continues to be a valid, though duplicate entry in the stack trace.
      
      With this change:
          $ sudo ./bcc/tools/offcputime.py -uU
          Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end.
      
          ^C
      	write
      	write
      	[unknown]
      	[unknown]
      	[unknown]
      	[unknown]
      	[unknown]
      	PyObject_VectorcallMethod
      	[unknown]
      	[unknown]
      	PyObject_CallOneArg
      	PyFile_WriteObject
      	PyFile_WriteString
      	[unknown]
      	[unknown]
      	PyObject_Vectorcall
      	_PyEval_EvalFrameDefault
      	PyEval_EvalCode
      	[unknown]
      	[unknown]
      	[unknown]
      	_PyRun_SimpleFileObject
      	_PyRun_AnyFileObject
      	Py_RunMain
      	[unknown]
      	Py_BytesMain
      	[unknown]
      	__libc_start_main
      	-                python (1293)
      	    7
      
      	write
      	write
      	[unknown]
      	sudo_ev_loop_v1
      	sudo_ev_dispatch_v1
      	[unknown]
      	[unknown]
      	[unknown]
      	[unknown]
      	__libc_start_main
      	-                sudo (1291)
      	    7
      
      	syscall
      	syscall
      	bpf_open_perf_buffer_opts
      	[unknown]
      	[unknown]
      	[unknown]
      	[unknown]
      	_PyObject_MakeTpCall
      	PyObject_Vectorcall
      	_PyEval_EvalFrameDefault
      	PyEval_EvalCode
      	[unknown]
      	[unknown]
      	[unknown]
      	_PyRun_SimpleFileObject
      	_PyRun_AnyFileObject
      	Py_RunMain
      	[unknown]
      	Py_BytesMain
      	[unknown]
      	__libc_start_main
      	-                python (1293)
      	    11
      
      	clock_nanosleep
      	clock_nanosleep
      	nanosleep
      	sleep
      	[unknown]
      	[unknown]
      	__clone
      	-                multipathd (698)
      	    3001661
      
      Fixes: 7fa95f9a ("powerpc/64s: system call support for scv/rfscv instructions")
      Cc: stable@vger.kernel.org
      Reported-by: default avatar"Nysal Jan K.A" <nysal@linux.ibm.com>
      Signed-off-by: default avatarNaveen N Rao <naveen@kernel.org>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org
      aad98efd
    • Gaurav Batra's avatar
      powerpc/pseries/iommu: Fix iommu initialisation during DLPAR add · ed8b94f6
      Gaurav Batra authored
      When a PCI device is dynamically added, the kernel oopses with a NULL
      pointer dereference:
      
        BUG: Kernel NULL pointer dereference on read at 0x00000030
        Faulting instruction address: 0xc0000000006bbe5c
        Oops: Kernel access of bad area, sig: 11 [#1]
        LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
        Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse
        CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66
        Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
        NIP:  c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8
        REGS: c00000009924f240 TRAP: 0300   Not tainted  (6.7.0-203405+)
        MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24002220  XER: 20040006
        CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0
        ...
        NIP sysfs_add_link_to_group+0x34/0x94
        LR  iommu_device_link+0x5c/0x118
        Call Trace:
         iommu_init_device+0x26c/0x318 (unreliable)
         iommu_device_link+0x5c/0x118
         iommu_init_device+0xa8/0x318
         iommu_probe_device+0xc0/0x134
         iommu_bus_notifier+0x44/0x104
         notifier_call_chain+0xb8/0x19c
         blocking_notifier_call_chain+0x64/0x98
         bus_notify+0x50/0x7c
         device_add+0x640/0x918
         pci_device_add+0x23c/0x298
         of_create_pci_dev+0x400/0x884
         of_scan_pci_dev+0x124/0x1b0
         __of_scan_bus+0x78/0x18c
         pcibios_scan_phb+0x2a4/0x3b0
         init_phb_dynamic+0xb8/0x110
         dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]
         add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]
         kobj_attr_store+0x2c/0x48
         sysfs_kf_write+0x64/0x78
         kernfs_fop_write_iter+0x1b0/0x290
         vfs_write+0x350/0x4a0
         ksys_write+0x84/0x140
         system_call_exception+0x124/0x330
         system_call_vectored_common+0x15c/0x2ec
      
      Commit a9409044 ("powerpc/iommu: Add iommu_ops to report capabilities
      and allow blocking domains") broke DLPAR add of PCI devices.
      
      The above added iommu_device structure to pci_controller. During
      system boot, PCI devices are discovered and this newly added iommu_device
      structure is initialized by a call to iommu_device_register().
      
      During DLPAR add of a PCI device, a new pci_controller structure is
      allocated but there are no calls made to iommu_device_register()
      interface.
      
      Fix is to register the iommu device during DLPAR add as well.
      
      Fixes: a9409044 ("powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains")
      Signed-off-by: default avatarGaurav Batra <gbatra@linux.ibm.com>
      [mpe: Trim oops and tweak some change log wording]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20240122222407.39603-1-gbatra@linux.ibm.com
      ed8b94f6
    • Nathan Lynch's avatar
      powerpc/pseries/papr-sysparm: use u8 arrays for payloads · 8ded03ae
      Nathan Lynch authored
      Some PAPR system parameter values are formatted by firmware as
      nul-terminated strings (e.g. LPAR name, shared processor attributes).
      But the values returned for other parameters, such as processor module
      info and TLB block invalidate characteristics, are binary data with
      parameter-specific layouts. So char[] isn't the appropriate type for
      the general case. Use u8/__u8.
      Signed-off-by: default avatarNathan Lynch <nathanl@linux.ibm.com>
      Fixes: 905b9e48 ("powerpc/pseries/papr-sysparm: Expose character device to user space")
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://msgid.link/20240202-papr-sysparm-ioblock-data-use-u8-v1-1-f5c6c89f65ec@linux.ibm.com
      8ded03ae
  2. 29 Jan, 2024 1 commit
  3. 28 Jan, 2024 7 commits
  4. 27 Jan, 2024 9 commits
  5. 26 Jan, 2024 20 commits