summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-05-04powerpc: 83xx/gpio: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250502-gpiochip-set-rv-powerpc-v2-2-488e43e325bf@linaro.org
2025-05-04powerpc: sysdev/gpio: use new line value setter callbacksBartosz Golaszewski
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250502-gpiochip-set-rv-powerpc-v2-1-488e43e325bf@linaro.org
2025-05-02Documentation: Fix description format for powerpc RTAS ioctlsHaren Myneni
Fix the description format for the following build warnings: "Documentation/userspace-api/ioctl/ioctl-number.rst:369: ERROR: Malformed table. Text in column margin in table line 301. 0xB2 03-05 arch/powerpc/include/uapi/asm/papr-indices.h powerpc/pseries indices API <mailto:linuxppc-dev> 0xB2 06-07 arch/powerpc/include/uapi/asm/papr-platform-dump.h powerpc/pseries Platform Dump API <mailto:linuxppc-dev> 0xB2 08 arch/powerpc/include/uapi/asm/papr-physical-attestation.h powerpc/pseries Physical Attestation API <mailto:linuxppc-dev>" Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Haren Myneni <haren@linux.ibm.com> Fixes: 43d869ac25f1 ("powerpc/pseries: Define papr_indices_io_block for papr-indices ioctls") Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver for dump retrieval") Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for physical-attestation RTAS") Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Closes: https://lore.kernel.org/linux-next/20250429181707.7848912b@canb.auug.org.au/ Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250430022847.1118093-1-haren@linux.ibm.com
2025-05-02powerpc/pseries: Include linux/types.h in papr-platform-dump.hHaren Myneni
Fix the following build warning: usr/include/asm/papr-platform-dump.h:12: found __[us]{8,16,32,64} type without #include <linux/types.h> Fixes: 8aa9efc0be66 ("powerpc/pseries: Add papr-platform-dump character driver for dump retrieval") Closes: https://lore.kernel.org/linux-next/20250429185735.034ba678@canb.auug.org.au/ Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> [Maddy: fixed the commit to combine tags together] Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250429211419.1081354-1-haren@linux.ibm.com
2025-04-29powerpc: Don't use --- in kernel logsChristophe Leroy
When a kernel log containing --- at the start of a line is copied into a patch message, 'git am' drops everything located after that ---. Replace --- by ---- to avoid that. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/54a1f8d2c3fb5b95434039724c8c141052ae5cc0.1739346038.git.christophe.leroy@csgroup.eu
2025-04-29powerpc/crash: Fix non-smp kexec preparationEddie James
In non-smp configurations, crash_kexec_prepare is never called in the crash shutdown path. One result of this is that the crashing_cpu variable is never set, preventing crash_save_cpu from storing the NT_PRSTATUS elf note in the core dump. Fixes: c7255058b543 ("powerpc/crash: save cpu register data in crash_smp_send_stop()") Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250211162054.857762-1-eajames@linux.ibm.com
2025-04-29powerpc: do not build ppc_save_regs.o alwaysJiri Slaby (SUSE)
The Fixes commit below tried to add CONFIG_PPC_BOOK3S to one of the conditions to enable the build of ppc_save_regs.o. But it failed to do so, in fact. The commit omitted to add a dollar sign. Therefore, ppc_save_regs.o is built always these days (as "(CONFIG_PPC_BOOK3S)" is never an empty string). Fix this by adding the missing dollar sign. Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Fixes: fc2a5a6161a2 ("powerpc/64s: ppc_save_regs is now needed for all 64s builds") Acked-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250417105305.397128-1-jirislaby@kernel.org
2025-04-29powerpc/pseries/msi: Avoid reading PCI device registers in reduced power statesGautam Menghani
When a system is being suspended to RAM, the PCI devices are also suspended and the PPC code ends up calling pseries_msi_compose_msg() and this triggers the BUG_ON() in __pci_read_msi_msg() because the device at this point is in reduced power state. In reduced power state, the memory mapped registers of the PCI device are not accessible. To replicate the bug: 1. Make sure deep sleep is selected # cat /sys/power/mem_sleep s2idle [deep] 2. Make sure console is not suspended (so that dmesg logs are visible) echo N > /sys/module/printk/parameters/console_suspend 3. Suspend the system echo mem > /sys/power/state To fix this behaviour, read the cached msi message of the device when the device is not in PCI_D0 power state instead of touching the hardware. Fixes: a5f3d2c17b07 ("powerpc/pseries/pci: Add MSI domains") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Gautam Menghani <gautam@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250305090237.294633-1-gautam@linux.ibm.com
2025-04-29powerpc/bpf: fix JIT code size calculation of bpf trampolineHari Bathini
arch_bpf_trampoline_size() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in arch_bpf_trampoline_size() can vary from the actual size needed in arch_prepare_bpf_trampoline(). When the instructions accounted in arch_bpf_trampoline_size() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc which is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing. Fixes: d243b62b7bd3 ("powerpc64/bpf: Add support for bpf trampolines") Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Closes: https://lore.kernel.org/all/6168bfc8-659f-4b5a-a6fb-90a916dde3b3@linux.ibm.com/ Cc: stable@vger.kernel.org # v6.13+ Acked-by: Naveen N Rao (AMD) <naveen@kernel.org> Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250422082609.949301-1-hbathini@linux.ibm.com
2025-04-29powerpc64/ftrace: fix clobbered r15 during livepatchingHari Bathini
While r15 is clobbered always with PPC_FTRACE_OUT_OF_LINE, it is not restored in livepatch sequence leading to not so obvious fails like below: BUG: Unable to handle kernel data access on write at 0xc0000000000f9078 Faulting instruction address: 0xc0000000018ff958 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP: c0000000018ff958 LR: c0000000018ff930 CTR: c0000000009c0790 REGS: c00000005f2e7790 TRAP: 0300 Tainted: G K (6.14.0+) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 2822880b XER: 20040000 CFAR: c0000000008addc0 DAR: c0000000000f9078 DSISR: 0a000000 IRQMASK: 1 GPR00: c0000000018f2584 c00000005f2e7a30 c00000000280a900 c000000017ffa488 GPR04: 0000000000000008 0000000000000000 c0000000018f24fc 000000000000000d GPR08: fffffffffffe0000 000000000000000d 0000000000000000 0000000000008000 GPR12: c0000000009c0790 c000000017ffa480 c00000005f2e7c78 c0000000000f9070 GPR16: c00000005f2e7c90 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 c00000005f3efa80 c00000005f2e7c60 c00000005f2e7c88 GPR24: c00000005f2e7c60 0000000000000001 c0000000000f9078 0000000000000000 GPR28: 00007fff97960000 c000000017ffa480 0000000000000000 c0000000000f9078 ... Call Trace: check_heap_object+0x34/0x390 (unreliable) __mutex_unlock_slowpath.isra.0+0xe4/0x230 seq_read_iter+0x430/0xa90 proc_reg_read_iter+0xa4/0x200 vfs_read+0x41c/0x510 ksys_read+0xa4/0x190 system_call_exception+0x1d0/0x440 system_call_vectored_common+0x15c/0x2ec Fix it by restoring r15 always. Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line") Reported-by: Viktor Malik <vmalik@redhat.com> Closes: https://lore.kernel.org/lkml/1aec4a9a-a30b-43fd-b303-7a351caeccb7@redhat.com Cc: stable@vger.kernel.org # v6.13+ Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Tested-by: Viktor Malik <vmalik@redhat.com> Acked-by: Naveen N Rao (AMD) <naveen@kernel.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416191227.201146-1-hbathini@linux.ibm.com
2025-04-17powerpc/pseries: Add a char driver for physical-attestation RTASHaren Myneni
The RTAS call ibm,physical-attestation is used to retrieve information about the trusted boot state of the firmware and hypervisor on the system, and also Trusted Platform Modules (TPM) data if the system is TCG 2.0 compliant. This RTAS interface expects the caller to define different command structs such as RetrieveTPMLog, RetrievePlatformCertificat and etc, in a work area with a maximum size of 4K bytes and the response buffer will be returned in the same work area. The current implementation of this RTAS function is in the user space but allocation of the work area is restricted with the system lockdown. So this patch implements this RTAS function in the kernel and expose to the user space with open/ioctl/read interfaces. PAPR (2.13+ 21.3 ibm,physical-attestation) defines RTAS function: - Pass the command struct to obtain the response buffer for the specific command. - This RTAS function is sequence RTAS call and has to issue RTAS call multiple times to get the complete response buffer (max 64K). The hypervisor expects the first RTAS call with the sequence 1 and the subsequent calls with the sequence number returned from the previous calls. Expose these interfaces to user space with a /dev/papr-physical-attestation character device using the following programming model: int devfd = open("/dev/papr-physical-attestation"); int fd = ioctl(devfd, PAPR_PHY_ATTEST_IOC_HANDLE, struct papr_phy_attest_io_block); - The user space defines the command struct and requests the response for any command. - Obtain the complete response buffer and returned the buffer as blob to the command specific FD. size = read(fd, buf, len); - Can retrieve the response buffer once or multiple times until the end of BLOB buffer. Implemented this new kernel ABI support in librtas library for system lockdown Signed-off-by: Haren Myneni <haren@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-8-haren@linux.ibm.com
2025-04-17powerpc/pseries: Add papr-platform-dump character driver for dump retrievalHaren Myneni
ibm,platform-dump RTAS call in combination with writable mapping /dev/mem is issued to collect platform dump from the hypervisor and may need multiple calls to get the complete dump. The current implementation uses rtas_platform_dump() API provided by librtas library to issue these RTAS calls. But /dev/mem access by the user space is prohibited under system lockdown. The solution should be to restrict access to RTAS function in user space and provide kernel interfaces to collect dump. This patch adds papr-platform-dump character driver and expose standard interfaces such as open / ioctl/ read to user space in ways that are compatible with lockdown. PAPR (7.3.3.4.1 ibm,platform-dump) provides a method to obtain the complete dump: - Each dump will be identified by ID called dump tag. - A sequence of RTAS calls have to be issued until retrieve the complete dump. The hypervisor expects the first RTAS call with the sequence 0 and the subsequent calls with the sequence number returned from the previous calls. - The hypervisor returns "dump complete" status once the complete dump is retrieved. But expects one more RTAS call from the partition with the NULL buffer to invalidate dump which means the dump will be removed in the hypervisor. - Sequence of calls are allowed with different dump IDs at the same time but not with the same dump ID. Expose these interfaces to user space with a /dev/papr-platform-dump character device using the following programming model: int devfd = open("/dev/papr-platform-dump", O_RDONLY); int fd = ioctl(devfd,PAPR_PLATFORM_DUMP_IOC_CREATE_HANDLE, &dump_id) - Restrict user space to access with the same dump ID. Typically we do not expect user space requests the dump again for the same dump ID. char *buf = malloc(size); length = read(fd, buf, size); - size should be minimum 1K based on PAPR and <= 4K based on RTAS work area size. It will be restrict to RTAS work area size. Using 4K work area based on the current implementation in librtas library - Each read call issue RTAS call to get the data based on the size requirement and returns bytes returned from the hypervisor - If the previous call returns dump complete status, the next read returns 0 like EOF. ret = ioctl(PAPR_PLATFORM_DUMP_IOC_INVALIDATE, &dump_id) - RTAS call with NULL buffer to invalidates the dump. The read API should use the file descriptor obtained from ioctl based on dump ID so that gets dump contents for the corresponding dump ID. Implemented support in librtas (rtas_platform_dump()) for this new ABI to support system lockdown. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-7-haren@linux.ibm.com
2025-04-17powerpc/pseries: Add ibm,get-dynamic-sensor-state RTAS call supportHaren Myneni
The RTAS call ibm,get-dynamic-sensor-state is used to get the sensor state identified by the location code and the sensor token. The librtas library provides an API rtas_get_dynamic_sensor() which uses /dev/mem access for work area allocation but is restricted under system lockdown. This patch provides an interface with new ioctl PAPR_DYNAMIC_SENSOR_IOC_GET to the papr-indices character driver which executes this HCALL and copies the sensor state in the user specified ioctl buffer. Refer PAPR 7.3.19 ibm,get-dynamic-sensor-state for more information on this RTAS call. - User input parameters to the RTAS call: location code string and the sensor token Expose these interfaces to user space with a /dev/papr-indices character device using the following programming model: int fd = open("/dev/papr-indices", O_RDWR); int ret = ioctl(fd, PAPR_DYNAMIC_SENSOR_IOC_GET, struct papr_indices_io_block) - The user space specifies input parameters in papr_indices_io_block struct - Returned state for the specified sensor is copied to papr_indices_io_block.dynamic_param.state Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-6-haren@linux.ibm.com
2025-04-17powerpc/pseries: Add ibm,set-dynamic-indicator RTAS call supportHaren Myneni
The RTAS call ibm,set-dynamic-indicator is used to set the new indicator state identified by a location code. The current implementation uses rtas_set_dynamic_indicator() API provided by librtas library which allocates RMO buffer and issue this RTAS call in the user space. But /dev/mem access by the user space is prohibited under system lockdown. This patch provides an interface with new ioctl PAPR_DYNAMIC_INDICATOR_IOC_SET to the papr-indices character driver and expose this interface to the user space that is compatible with lockdown. Refer PAPR 7.3.18 ibm,set-dynamic-indicator for more information on this RTAS call. - User input parameters to the RTAS call: location code string, indicator token and new state Expose these interfaces to user space with a /dev/papr-indices character device using the following programming model: int fd = open("/dev/papr-indices", O_RDWR); int ret = ioctl(fd, PAPR_DYNAMIC_INDICATOR_IOC_SET, struct papr_indices_io_block) - The user space passes input parameters in papr_indices_io_block struct Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-5-haren@linux.ibm.com
2025-04-17powerpc/pseries: Add papr-indices char driver for ibm,get-indicesHaren Myneni
The RTAS call ibm,get-indices is used to obtain indices and location codes for a specified indicator or sensor token. The current implementation uses rtas_get_indices() API provided by librtas library which allocates RMO buffer and issue this RTAS call in the user space. But writable mapping /dev/mem access by the user space is prohibited under system lockdown. To overcome the restricted access in the user space, the kernel provide interfaces to collect indices data from the hypervisor. This patch adds papr-indices character driver and expose standard interfaces such as open / ioctl/ read to user space in ways that are compatible with lockdown. PAPR (2.13 7.3.17 ibm,get-indices RTAS Call) describes the following steps to retrieve all indices data: - User input parameters to the RTAS call: sensor or indicator, and indice type - ibm,get-indices is sequence RTAS call which means has to issue multiple times to get the entire list of indicators or sensors of a particular type. The hypervisor expects the first RTAS call with the sequence 1 and the subsequent calls with the sequence number returned from the previous calls. - The OS may not interleave calls to ibm,get-indices for different indicator or sensor types. Means other RTAS calls with different type should not be issued while the previous type sequence is in progress. So collect the entire list of indices and copied to buffer BLOB during ioctl() and expose this buffer to the user space with the file descriptor. - The hypervisor fills the work area with a specific format but does not return the number of bytes written to the buffer. Instead of parsing the data for each call to determine the data length, copy the work area size (RTAS_GET_INDICES_BUF_SIZE) to the buffer. Return work-area size of data to the user space for each read() call. Expose these interfaces to user space with a /dev/papr-indices character device using the following programming model: int devfd = open("/dev/papr-indices", O_RDONLY); int fd = ioctl(devfd, PAPR_INDICES_IOC_GET, struct papr_indices_io_block) - Collect all indices data for the specified token to the buffer char *buf = malloc(RTAS_GET_INDICES_BUF_SIZE); length = read(fd, buf, RTAS_GET_INDICES_BUF_SIZE) - RTAS_GET_INDICES_BUF_SIZE of data is returned to the user space. - The user space retrieves the indices and their location codes from the buffer - Should issue multiple read() calls until reaches the end of BLOB buffer. The read() should use the file descriptor obtained from ioctl to get the data that is exposed to file descriptor. Implemented support in librtas (rtas_get_indices()) for this new ABI for system lockdown. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-4-haren@linux.ibm.com
2025-04-17powerpc/pseries: Define papr_indices_io_block for papr-indices ioctlsHaren Myneni
To issue ibm,get-indices, ibm,set-dynamic-indicator and ibm,get-dynamic-sensor-state in the user space, the RMO buffer is allocated for the work area which is restricted under system lockdown. So instead of user space execution, the kernel will provide /dev/papr-indices interface to execute these RTAS calls. The user space assigns data in papr_indices_io_block struct depends on the specific HCALL and passes to the following ioctls: PAPR_INDICES_IOC_GET: Use for ibm,get-indices. Returns a get-indices handle fd to read data. PAPR_DYNAMIC_SENSOR_IOC_GET: Use for ibm,get-dynamic-sensor-state. Updates the sensor state in papr_indices_io_block.dynamic_param.state PAPR_DYNAMIC_INDICATOR_IOC_SET: Use for ibm,set-dynamic-indicator. Sets the new state for the input indicator. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-3-haren@linux.ibm.com
2025-04-17powerpc/pseries: Define common functions for RTAS sequence callsHaren Myneni
The RTAS call can be normal where retrieves the data form the hypervisor once or sequence based RTAS call which has to issue multiple times until the complete data is obtained. For some of these sequence RTAS calls, the OS should not interleave calls with different input until the sequence is completed. The data is collected for each call and copy to the buffer for the entire sequence during ioctl() handle and then expose this buffer to the user space with read() handle. One such sequence RTAS call is ibm,get-vpd and its support is already included in the current code. To add the similar support for other sequence based calls, move the common functions in to separate file and update papr_rtas_sequence struct with the following callbacks so that RTAS call specific code will be defined and executed to complete the sequence. struct papr_rtas_sequence { int error; void params; void (*begin) (struct papr_rtas_sequence *); void (*end) (struct papr_rtas_sequence *); const char * (*work) (struct papr_rtas_sequence *, size_t *); }; params: Input parameters used to pass for RTAS call. Begin: RTAS call specific function to initialize data including work area allocation. End: RTAS call specific function to free up resources (free work area) after the sequence is completed. Work: The actual RTAS call specific function which collects the data from the hypervisor. Signed-off-by: Haren Myneni <haren@linux.ibm.com> Tested-by: Sathvika Vasireddy <sv@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416225743.596462-2-haren@linux.ibm.com
2025-04-16powerpc: enable dynamic preemptionShrikanth Hegde
Once the lazy preemption is supported, it would be desirable to change the preemption models at runtime. So add support for dynamic preemption using DYNAMIC_KEY. ::Tested lightly on Power10 LPAR Performance numbers indicate that, preempt=none(no dynamic) and preempt=none(dynamic) are close. cat /sys/kernel/debug/sched/preempt (none) voluntary full lazy perf stat -e probe:__cond_resched -a sleep 1 Performance counter stats for 'system wide': 1,253 probe:__cond_resched echo full > /sys/kernel/debug/sched/preempt cat /sys/kernel/debug/sched/preempt none voluntary (full) lazy perf stat -e probe:__cond_resched -a sleep 1 Performance counter stats for 'system wide': 0 probe:__cond_resched Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250210184334.567383-2-sshegde@linux.ibm.com
2025-04-16fadump: Use str_yes_no() helper in fadump_show_config()Thorsten Blum
Remove hard-coded strings by using the str_yes_no() helper function. Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250209081704.2758-2-thorsten.blum@linux.dev
2025-04-16KVM: powerpc: Enable commented out BUILD_BUG_ON() assertionThorsten Blum
The BUILD_BUG_ON() assertion was commented out in commit 38634e676992 ("powerpc/kvm: Remove problematic BUILD_BUG_ON statement") and fixed in commit c0a187e12d48 ("KVM: powerpc: Fix BUILD_BUG_ON condition"), but not enabled. Enable it now that this no longer breaks and remove the comment. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250411084222.6916-1-thorsten.blum@linux.dev
2025-04-16powerpc: mpic: Use str_enabled_disabled() helper functionThorsten Blum
Remove hard-coded strings by using the str_enabled_disabled() helper function. Use pr_debug() instead of printk(KERN_DEBUG) to silence a checkpatch warning. Reviewed-by: Ricardo B. Marlière <ricardo@marliere.net> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250219112053.3352-2-thorsten.blum@linux.dev
2025-04-16powerpc/ps3: Use str_write_read() in ps3_notification_read_write()Thorsten Blum
Remove hard-coded strings by using the str_write_read() helper function. Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250219111445.2875-2-thorsten.blum@linux.dev
2025-04-16powerpc/kvm-hv-pmu: Add perf-events for Hostwide countersVaibhav Jain
Update 'kvm-hv-pmu.c' to add five new perf-events mapped to the five Hostwide counters. Since these newly introduced perf events are at system wide scope and can be read from any L1-Lpar CPU, 'kvmppc_pmu' scope and capabilities are updated appropriately. Also introduce two new helpers. First is kvmppc_update_l0_stats() that uses the infrastructure introduced in previous patches to issues the H_GUEST_GET_STATE hcall L0-PowerVM to fetch guest-state-buffer holding the latest values of these counters which is then parsed and 'l0_stats' variable updated. Second helper is kvmppc_pmu_event_update() which is called from 'kvmppv_pmu' callbacks and uses kvmppc_update_l0_stats() to update 'l0_stats' and the update the 'struct perf_event's event-counter. Some minor updates to kvmppc_pmu_{add, del, read}() to remove some debug scaffolding code. Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Reviewed-by: Athira Rajeev <atrajeev@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-7-vaibhav@linux.ibm.com
2025-04-16powerpc/kvm-hv-pmu: Implement GSB message-ops for hostwide countersVaibhav Jain
Implement and setup necessary structures to send a prepolulated Guest-State-Buffer(GSB) requesting hostwide counters to L0-PowerVM and have the returned GSB holding the values of these counters parsed. This is done via existing GSB implementation and with the newly added support of Hostwide elements in GSB. The request to L0-PowerVM to return Hostwide counters is done using a pre-allocated GSB named 'gsb_l0_stats'. To be able to populate this GSB with the needed Guest-State-Elements (GSIDs) a instance of 'struct kvmppc_gs_msg' named 'gsm_l0_stats' is introduced. The 'gsm_l0_stats' is tied to an instance of 'struct kvmppc_gs_msg_ops' named 'gsb_ops_l0_stats' which holds various callbacks to be compute the size ( hostwide_get_size() ), populate the GSB ( hostwide_fill_info() ) and refresh ( hostwide_refresh_info() ) the contents of 'l0_stats' that holds the Hostwide counters returned from L0-PowerVM. To protect these structures from simultaneous access a spinlock 'lock_l0_stats' has been introduced. The allocation and initialization of the above structures is done in newly introduced kvmppc_init_hostwide() and similarly the cleanup is performed in newly introduced kvmppc_cleanup_hostwide(). Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-6-vaibhav@linux.ibm.com
2025-04-16kvm powerpc/book3s-apiv2: Introduce kvm-hv specific PMUVaibhav Jain
Introduce a new PMU named 'kvm-hv' inside a new module named 'kvm-hv-pmu' to report Book3s kvm-hv specific performance counters. This will expose KVM-HV specific performance attributes to user-space via kernel's PMU infrastructure and would enableusers to monitor active kvm-hv based guests. The patch creates necessary scaffolding to for the new PMU callbacks and introduces the new kernel module name 'kvm-hv-pmu' which is built with CONFIG_KVM_BOOK3S_HV_PMU. The patch doesn't introduce any perf-events yet, which will be introduced in later patches Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-5-vaibhav@linux.ibm.com
2025-04-16kvm powerpc/book3s-apiv2: Add kunit tests for Hostwide GSB elementsVaibhav Jain
Update 'test-guest-state-buffer.c' to add two new KUNIT test cases for validating correctness of changes to Guest-state-buffer management infrastructure for adding support for Hostwide GSB elements. The newly introduced test test_gs_hostwide_msg() checks if the Hostwide elements can be set and parsed from a Guest-state-buffer. The second kunit test test_gs_hostwide_counters() checks if the Hostwide GSB elements can be send to the L0-PowerVM hypervisor via the H_GUEST_SET_STATE hcall and ensures that the returned guest-state-buffer has all the 5 Hostwide stat counters present. Below is the KATP test report with the newly added KUNIT tests: KTAP version 1 # Subtest: guest_state_buffer_test # module: test_guest_state_buffer 1..7 ok 1 test_creating_buffer ok 2 test_adding_element ok 3 test_gs_bitmap ok 4 test_gs_parsing ok 5 test_gs_msg ok 6 test_gs_hostwide_msg # test_gs_hostwide_counters: Guest Heap Size=0 bytes # test_gs_hostwide_counters: Guest Heap Size Max=10995367936 bytes # test_gs_hostwide_counters: Guest Page-table Size=2178304 bytes # test_gs_hostwide_counters: Guest Page-table Size Max=2147483648 bytes # test_gs_hostwide_counters: Guest Page-table Reclaim Size=0 bytes ok 7 test_gs_hostwide_counters # guest_state_buffer_test: pass:7 fail:0 skip:0 total:7 # Totals: pass:7 fail:0 skip:0 total:7 ok 1 guest_state_buffer_test Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-4-vaibhav@linux.ibm.com
2025-04-16kvm powerpc/book3s-apiv2: Add support for Hostwide GSB elementsVaibhav Jain
Add support for adding and parsing Hostwide elements to the Guest-state-buffer data structure used in apiv2. These elements are used to share meta-information pertaining to entire L1-Lpar and this meta-information is maintained by L0-PowerVM hypervisor. Example of this include the amount of the page-table memory currently used by L0-PowerVM for hosting the Shadow-Pagetable of all active L2-Guests. More of the are documented in kernel-documentation at [1]. The Hostwide GSB elements are currently only support with H_GUEST_SET_STATE hcall with a special flag namely 'KVMPPC_GS_FLAGS_HOST_WIDE'. The patch introduces new defs for the 5 new Hostwide GSB elements including their GSIDs as well as introduces a new class of GSB elements namely 'KVMPPC_GS_CLASS_HOSTWIDE' to indicate to GSB construction/parsing infrastructure in 'kvm/guest-state-buffer.c'. Also gs_msg_ops_vcpu_get_size(), kvmppc_gsid_type() and kvmppc_gse_{flatten,unflatten}_iden() are updated to appropriately indicate the needed size for these Hostwide GSB elements as well as how to flatten/unflatten their GSIDs so that they can be marked as available in GSB bitmap. [1] Documention/arch/powerpc/kvm-nested.rst Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-3-vaibhav@linux.ibm.com
2025-04-16powerpc: Document APIv2 KVM hcall spec for Hostwide countersVaibhav Jain
Update kvm-nested APIv2 documentation to include five new Guest-State-Elements to fetch the hostwide counters. These counters are per L1-Lpar and indicate the amount of Heap/Page-table memory allocated, available and Page-table memory reclaimed for all L2-Guests active instances Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Tested-by: Gautam Menghani <gautam@linux.ibm.com> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20250416162740.93143-2-vaibhav@linux.ibm.com
2025-04-13Linux 6.15-rc2v6.15-rc2Linus Torvalds
2025-04-13Merge tag 'erofs-for-6.15-rc2-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs Pull erofs fixes from Gao Xiang: - Properly handle errors when file-backed I/O fails - Fix compilation issues on ARM platform (arm-linux-gnueabi) - Fix parsing of encoded extents - Minor cleanup * tag 'erofs-for-6.15-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs: erofs: remove duplicate code erofs: fix encoded extents handling erofs: add __packed annotation to union(__le16..) erofs: set error to bio if file-backed IO fails
2025-04-13Merge tag 'ext4_for_linus-6.15-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fixes from Ted Ts'o: "A few more miscellaneous ext4 bug fixes and cleanups including some syzbot failures and fixing a stale file handing refeencing an inode previously used as a regular file, but which has been deleted and reused as an ea_inode would result in ext4 erroneously considering this a case of fs corruption" * tag 'ext4_for_linus-6.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: fix off-by-one error in do_split ext4: make block validity check resistent to sb bh corruption ext4: avoid -Wflex-array-member-not-at-end warning Documentation: ext4: Add fields to ext4_super_block documentation ext4: don't treat fhandle lookup of ea_inode as FS corruption
2025-04-13Merge tag 'fixes-2025-04-13' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock Pull memblock fix from Mike Rapoport: "Fix build of memblock test. Add missing stubs for mutex and free_reserved_area() to memblock tests" * tag 'fixes-2025-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock: memblock tests: Fix mutex related build error
2025-04-12ext4: fix off-by-one error in do_splitArtem Sadovnikov
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split. BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The following loop is located right above 'if' statement. for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } 'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Fixes: 5872331b3d91 ("ext4: fix potential negative array index in do_split()") Signed-off-by: Artem Sadovnikov <a.sadovnikov@ispras.ru> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20250404082804.2567-3-a.sadovnikov@ispras.ru Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12ext4: make block validity check resistent to sb bh corruptionOjaswin Mujoo
Block validity checks need to be skipped in case they are called for journal blocks since they are part of system's protected zone. Currently, this is done by checking inode->ino against sbi->s_es->s_journal_inum, which is a direct read from the ext4 sb buffer head. If someone modifies this underneath us then the s_journal_inum field might get corrupted. To prevent against this, change the check to directly compare the inode with journal->j_inode. **Slight change in behavior**: During journal init path, check_block_validity etc might be called for journal inode when sbi->s_journal is not set yet. In this case we now proceed with ext4_inode_block_valid() instead of returning early. Since systems zones have not been set yet, it is okay to proceed so we can perform basic checks on the blocks. Suggested-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Link: https://patch.msgid.link/0c06bc9ebfcd6ccfed84a36e79147bf45ff5adc1.1743142920.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12ext4: avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are getting ready to enable it, globally. Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with these changes, fix the following warning: fs/ext4/mballoc.c:3041:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Link: https://patch.msgid.link/Z-SF97N3AxcIMlSi@kspp Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12Documentation: ext4: Add fields to ext4_super_block documentationTom Vierjahn
Documentation and implementation of the ext4 super block have slightly diverged: Padding has been removed in order to make room for new fields that are still missing in the documentation. Add the new fields s_encryption_level, s_first_error_errorcode, s_last_error_errorcode to the documentation of the ext4 super block. Fixes: f542fbe8d5e8 ("ext4 crypto: reserve codepoints used by the ext4 encryption feature") Fixes: 878520ac45f9 ("ext4: save the error code which triggered an ext4_error() in the superblock") Signed-off-by: Tom Vierjahn <tom.vierjahn@acm.org> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Link: https://patch.msgid.link/20250324221004.5268-1-tom.vierjahn@acm.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-04-12Merge tag 'trace-v6.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Hide get_vm_area() from MMUless builds The function get_vm_area() is not defined when CONFIG_MMU is not defined. Hide that function within #ifdef CONFIG_MMU. - Fix output of synthetic events when they have dynamic strings The print fmt of the synthetic event's format file use to have "%.*s" for dynamic size strings even though the user space exported arguments had only __get_str() macro that provided just a nul terminated string. This was fixed so that user space could parse this properly. But the reason that it had "%.*s" was because internally it provided the maximum size of the string as one of the arguments. The fix that replaced "%.*s" with "%s" caused the trace output (when the kernel reads the event) to write "(efault)" as it would now read the length of the string as "%s". As the string provided is always nul terminated, there's no reason for the internal code to use "%.*s" anyway. Just remove the length argument to match the "%s" that is now in the format. - Fix the ftrace subops hash logic of the manager ops hash The function_graph uses the ftrace subops code. The subops code is a way to have a single ftrace_ops registered with ftrace to determine what functions will call the ftrace_ops callback. More than one user of function graph can register a ftrace_ops with it. The function graph infrastructure will then add this ftrace_ops as a subops with the main ftrace_ops it registers with ftrace. This is because the functions will always call the function graph callback which in turn calls the subops ftrace_ops callbacks. The main ftrace_ops must add a callback to all the functions that the subops want a callback from. When a subops is registered, it will update the main ftrace_ops hash to include the functions it wants. This is the logic that was broken. The ftrace_ops hash has a "filter_hash" and a "notrace_hash" where all the functions in the filter_hash but not in the notrace_hash are attached by ftrace. The original logic would have the main ftrace_ops filter_hash be a union of all the subops filter_hashes and the main notrace_hash would be a intersect of all the subops filter hashes. But this was incorrect because the notrace hash depends on the filter_hash it is associated to and not the union of all filter_hashes. Instead, when a subops is added, just include all the functions of the subops hash that are in its filter_hash but not in its notrace_hash. The main subops hash should not use its notrace hash, unless all of its subops hashes have an empty filter_hash (which means to attach to all functions), and then, and only then, the main ftrace_ops notrace hash can be the intersect of all the subops hashes. This not only fixes the bug, but also simplifies the code. - Add a selftest to better test the subops filtering Add a selftest that would catch the bug fixed by the above change. - Fix extra newline printed in function tracing with retval The function parameter code changed the output logic slightly and called print_graph_retval() and also printed a newline. The print_graph_retval() also prints a newline which caused blank lines to be printed in the function graph tracer when retval was added. This caused one of the selftests to fail if retvals were enabled. Instead remove the new line output from print_graph_retval() and have the callers always print the new line so that it doesn't have to do special logic if it calls print_graph_retval() or not. - Fix out-of-bound memory access in the runtime verifier When rv_is_container_monitor() is called on the last entry on the link list it references the next entry, which is the list head and causes an out-of-bound memory access. * tag 'trace-v6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: rv: Fix out-of-bound memory access in rv_is_container_monitor() ftrace: Do not have print_graph_retval() add a newline tracing/selftest: Add test to better test subops filtering of function graph ftrace: Fix accounting of subop hashes ftrace: Properly merge notrace hashes tracing: Do not add length to print format in synthetic events tracing: Hide get_vm_area() from MMUless builds
2025-04-12Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull bpf fixes from Alexei Starovoitov: - Followup fixes for resilient spinlock (Kumar Kartikeya Dwivedi): - Make res_spin_lock test less verbose, since it was spamming BPF CI on failure, and make the check for AA deadlock stronger - Fix rebasing mistake and use architecture provided res_smp_cond_load_acquire - Convert BPF maps (queue_stack and ringbuf) to resilient spinlock to address long standing syzbot reports - Make sure that classic BPF load instruction from SKF_[NET|LL]_OFF offsets works when skb is fragmeneted (Willem de Bruijn) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Convert ringbuf map to rqspinlock bpf: Convert queue_stack map to rqspinlock bpf: Use architecture provided res_smp_cond_load_acquire selftests/bpf: Make res_spin_lock AA test condition stronger selftests/net: test sk_filter support for SKF_NET_OFF on frags bpf: support SKF_NET_OFF and SKF_LL_OFF on skb frags selftests/bpf: Make res_spin_lock test less verbose
2025-04-12rv: Fix out-of-bound memory access in rv_is_container_monitor()Nam Cao
When rv_is_container_monitor() is called on the last monitor in rv_monitors_list, KASAN yells: BUG: KASAN: global-out-of-bounds in rv_is_container_monitor+0x101/0x110 Read of size 8 at addr ffffffff97c7c798 by task setup/221 The buggy address belongs to the variable: rv_monitors_list+0x18/0x40 This is due to list_next_entry() is called on the last entry in the list. It wraps around to the first list_head, and the first list_head is not embedded in struct rv_monitor_def. Fix it by checking if the monitor is last in the list. Cc: stable@vger.kernel.org Cc: Gabriele Monaco <gmonaco@redhat.com> Fixes: cb85c660fcd4 ("rv: Add option for nested monitors and include sched") Link: https://lore.kernel.org/e85b5eeb7228bfc23b8d7d4ab5411472c54ae91b.1744355018.git.namcao@linutronix.de Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-12ftrace: Do not have print_graph_retval() add a newlineSteven Rostedt
The retval and retaddr options for function_graph tracer will add a comment at the end of a function for both leaf and non leaf functions that looks like: __wake_up_common(); /* ret=0x1 */ } /* pick_next_task_fair ret=0x0 */ The function print_graph_retval() adds a newline after the "*/". But if that's not called, the caller function needs to make sure there's a newline added. This is confusing and when the function parameters code was added, it added a newline even when calling print_graph_retval() as the fact that the print_graph_retval() function prints a newline isn't obvious. This caused an extra newline to be printed and that made it fail the selftests when the retval option was set, as the selftests were not expecting blank lines being injected into the trace. Instead of having print_graph_retval() print a newline, just have the caller always print the newline regardless if it calls print_graph_retval() or not. This not only fixes this bug, but it also simplifies the code. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/20250411133015.015ca393@gandalf.local.home Reported-by: Mark Brown <broonie@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/ccc40f2b-4b9e-4abd-8daf-d22fce2a86f0@sirena.org.uk/ Fixes: ff5c9c576e754 ("ftrace: Add support for function argument to graph tracer") Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-12Merge tag 'pwm/for-6.15-rc2-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux Pull pwm fixes from Uwe Kleine-König: "A set of fixes for pwm core and various drivers The first three patches handle clk_get_rate() returning 0 (which might happen for example if the CCF is disabled). The first of these was found because this triggered a warning with clang, the two others by looking for similar issues in other drivers. The remaining three fixes address issues in the new waveform pwm API. Now that I worked on this a bit more, the finer details and corner cases are better understood and the code is fixed accordingly" * tag 'pwm/for-6.15-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux: pwm: axi-pwmgen: Let .round_waveform_tohw() signal when request was rounded up pwm: stm32: Search an appropriate duty_cycle if period cannot be modified pwm: Let pwm_set_waveform() succeed even if lowlevel driver rounded up pwm: fsl-ftm: Handle clk_get_rate() returning 0 pwm: rcar: Improve register calculation pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
2025-04-11Merge tag 'v6.15-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull smb client fixes from Steve French: - Fix multichannel decryption UAF - Fix regression mounting to onedrive shares - Fix missing mount option check for posix vs. noposix - Fix version field in WSL symlinks - Three minor cleanup to reparse point handling - SMB1 fix for WSL special files - SMB1 Kerberos fix - Add SMB3 defines for two new FS attributes * tag 'v6.15-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: smb3: Add defines for two new FileSystemAttributes cifs: Fix querying of WSL CHR and BLK reparse points over SMB1 cifs: Split parse_reparse_point callback to functions: get buffer and parse buffer cifs: Improve handling of name surrogate reparse points in reparse.c cifs: Remove explicit handling of IO_REPARSE_TAG_MOUNT_POINT in inode.c cifs: Fix encoding of SMB1 Session Setup Kerberos Request in non-UNICODE mode smb: client: fix UAF in decryption with multichannel cifs: Fix support for WSL-style symlinks smb311 client: fix missing tcon check when mounting with linux/posix extensions cifs: Ensure that all non-client-specific reparse points are processed by the server
2025-04-11Merge tag 'pci-v6.15-fixes-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull pci fix from Bjorn Helgaas: - Run quirk_huawei_pcie_sva() before arm_smmu_probe_device(), which depends on the quirk, to avoid IOMMU initialization failures (Zhangfei Gao) * tag 'pci-v6.15-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: Run quirk_huawei_pcie_sva() before arm_smmu_probe_device()
2025-04-11tracing/selftest: Add test to better test subops filtering of function graphSteven Rostedt
A bug was discovered that showed the accounting of the subops of the ftrace_ops filtering was incorrect. Add a new test to better test the filtering. This test creates two instances, where it will add various filters to both the set_ftrace_filter and the set_ftrace_notrace files and enable function_graph. Then it looks into the enabled_functions file to make sure that the filters are behaving correctly. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/20250409152720.380778379@goodmis.org Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-11ftrace: Fix accounting of subop hashesSteven Rostedt
The function graph infrastructure uses ftrace to hook to functions. It has a single ftrace_ops to manage all the users of function graph. Each individual user (tracing, bpf, fprobes, etc) has its own ftrace_ops to track the functions it will have its callback called from. These ftrace_ops are "subops" to the main ftrace_ops of the function graph infrastructure. Each ftrace_ops has a filter_hash and a notrace_hash that is defined as: Only trace functions that are in the filter_hash but not in the notrace_hash. If the filter_hash is empty, it means to trace all functions. If the notrace_hash is empty, it means do not disable any function. The function graph main ftrace_ops needs to be a superset containing all the functions to be traced by all the subops it has. The algorithm to perform this merge was incorrect. When the first subops was added to the main ops, it simply made the main ops a copy of the subops (same filter_hash and notrace_hash). When a second ops was added, it joined the new subops filter_hash with the main ops filter_hash as a union of the two sets. The intersect between the new subops notrace_hash and the main ops notrace_hash was created as the new notrace_hash of the main ops. The issue here is that it would then start tracing functions than no subops were tracing. For example if you had two subops that had: subops 1: filter_hash = '*sched*' # trace all functions with "sched" in it notrace_hash = '*time*' # except do not trace functions with "time" subops 2: filter_hash = '*lock*' # trace all functions with "lock" in it notrace_hash = '*clock*' # except do not trace functions with "clock" The intersect of '*time*' functions with '*clock*' functions could be the empty set. That means the main ops will be tracing all functions with '*time*' and all "*clock*" in it! Instead, modify the algorithm to be a bit simpler and correct. First, when adding a new subops, even if it's the first one, do not add the notrace_hash if the filter_hash is not empty. Instead, just add the functions that are in the filter_hash of the subops but not in the notrace_hash of the subops into the main ops filter_hash. There's no reason to add anything to the main ops notrace_hash. The notrace_hash of the main ops should only be non empty iff all subops filter_hashes are empty (meaning to trace all functions) and all subops notrace_hashes include the same functions. That is, the main ops notrace_hash is empty if any subops filter_hash is non empty. The main ops notrace_hash only has content in it if all subops filter_hashes are empty, and the content are only functions that intersect all the subops notrace_hashes. If any subops notrace_hash is empty, then so is the main ops notrace_hash. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: Andy Chiu <andybnac@gmail.com> Link: https://lore.kernel.org/20250409152720.216356767@goodmis.org Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-11ftrace: Properly merge notrace hashesAndy Chiu
The global notrace hash should be jointly decided by the intersection of each subops's notrace hash, but not the filter hash. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20250408160258.48563-1-andybnac@gmail.com Fixes: 5fccc7552ccb ("ftrace: Add subops logic to allow one ops to manage many") Signed-off-by: Andy Chiu <andybnac@gmail.com> [ fixed removing of freeing of filter_hash ] Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-04-11PCI: Run quirk_huawei_pcie_sva() before arm_smmu_probe_device()Zhangfei Gao
quirk_huawei_pcie_sva() sets properties needed by arm_smmu_probe_device(), but bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") changed the iommu_probe_device() flow so arm_smmu_probe_device() is now invoked before the quirk, leading to failures like this: reg-dummy reg-dummy: late IOMMU probe at driver bind, something fishy here! WARNING: CPU: 0 PID: 1 at drivers/iommu/iommu.c:449 __iommu_probe_device+0x140/0x570 RIP: 0010:__iommu_probe_device+0x140/0x570 The SR-IOV enumeration ordering changes like this: pci_iov_add_virtfn pci_device_add pci_fixup_device(pci_fixup_header) <-- device_add bus_notify iommu_bus_notifier + iommu_probe_device + arm_smmu_probe_device pci_bus_add_device pci_fixup_device(pci_fixup_final) <-- device_attach driver_probe_device really_probe pci_dma_configure acpi_dma_configure_id - iommu_probe_device - arm_smmu_probe_device The non-SR-IOV case is similar in that pci_device_add() is called from pci_scan_single_device() in the generic enumeration path and pci_bus_add_device() is called later, after all host bridges have been enumerated. Declare quirk_huawei_pcie_sva() as a header fixup to ensure that it happens before arm_smmu_probe_device(). Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path") Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Closes: https://lore.kernel.org/all/SJ1PR11MB61295DE21A1184AEE0786E25B9D22@SJ1PR11MB6129.namprd11.prod.outlook.com/ Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> [bhelgaas: commit log, add failure info and reporter] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250317011352.5806-1-zhangfei.gao@linaro.org
2025-04-11bpf: Convert ringbuf map to rqspinlockKumar Kartikeya Dwivedi
Convert the raw spinlock used by BPF ringbuf to rqspinlock. Currently, we have an open syzbot report of a potential deadlock. In addition, the ringbuf can fail to reserve spuriously under contention from NMI context. It is potentially attractive to enable unconstrained usage (incl. NMIs) while ensuring no deadlocks manifest at runtime, perform the conversion to rqspinlock to achieve this. This change was benchmarked for BPF ringbuf's multi-producer contention case on an Intel Sapphire Rapids server, with hyperthreading disabled and performance governor turned on. 5 warm up runs were done for each case before obtaining the results. Before (raw_spinlock_t): Ringbuf, multi-producer contention ================================== rb-libbpf nr_prod 1 11.440 ± 0.019M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 2 2.706 ± 0.010M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 3 3.130 ± 0.004M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 4 2.472 ± 0.003M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 8 2.352 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 12 2.813 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 16 1.988 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 20 2.245 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 24 2.148 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 28 2.190 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 32 2.490 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 36 2.180 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 40 2.201 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 44 2.226 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 48 2.164 ± 0.001M/s (drops 0.000 ± 0.000M/s) rb-libbpf nr_prod 52 1.874 ± 0.001M/s (drops 0.000 ± 0.000M/s) After (rqspinlock_t): Ringbuf, multi-producer contention ================================== rb-libbpf nr_prod 1 11.078 ± 0.019M/s (drops 0.000 ± 0.000M/s) (-3.16%) rb-libbpf nr_prod 2 2.801 ± 0.014M/s (drops 0.000 ± 0.000M/s) (3.51%) rb-libbpf nr_prod 3 3.454 ± 0.005M/s (drops 0.000 ± 0.000M/s) (10.35%) rb-libbpf nr_prod 4 2.567 ± 0.002M/s (drops 0.000 ± 0.000M/s) (3.84%) rb-libbpf nr_prod 8 2.468 ± 0.001M/s (drops 0.000 ± 0.000M/s) (4.93%) rb-libbpf nr_prod 12 2.510 ± 0.001M/s (drops 0.000 ± 0.000M/s) (-10.77%) rb-libbpf nr_prod 16 2.075 ± 0.001M/s (drops 0.000 ± 0.000M/s) (4.38%) rb-libbpf nr_prod 20 2.640 ± 0.001M/s (drops 0.000 ± 0.000M/s) (17.59%) rb-libbpf nr_prod 24 2.092 ± 0.001M/s (drops 0.000 ± 0.000M/s) (-2.61%) rb-libbpf nr_prod 28 2.426 ± 0.005M/s (drops 0.000 ± 0.000M/s) (10.78%) rb-libbpf nr_prod 32 2.331 ± 0.004M/s (drops 0.000 ± 0.000M/s) (-6.39%) rb-libbpf nr_prod 36 2.306 ± 0.003M/s (drops 0.000 ± 0.000M/s) (5.78%) rb-libbpf nr_prod 40 2.178 ± 0.002M/s (drops 0.000 ± 0.000M/s) (-1.04%) rb-libbpf nr_prod 44 2.293 ± 0.001M/s (drops 0.000 ± 0.000M/s) (3.01%) rb-libbpf nr_prod 48 2.022 ± 0.001M/s (drops 0.000 ± 0.000M/s) (-6.56%) rb-libbpf nr_prod 52 1.809 ± 0.001M/s (drops 0.000 ± 0.000M/s) (-3.47%) There's a fair amount of noise in the benchmark, with numbers on reruns going up and down by 10%, so all changes are in the range of this disturbance, and we see no major regressions. Reported-by: syzbot+850aaf14624dc0c6d366@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/0000000000004aa700061379547e@google.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20250411101759.4061366-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-04-11Merge tag 'spi-fix-v6.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A couple of cleanups for the error handling in the Freescale drivers" * tag 'spi-fix-v6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: fsl-spi: Remove redundant probe error message spi: fsl-qspi: Fix double cleanup in probe error path
2025-04-11Merge tag 'ata-6.15-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Damien Le Moal: - Fix missing error checks during controller probe in the sata_sx4 driver (Wentao) - Fix missing error checks during controller probe in the pata_pxa driver (Henry) * tag 'ata-6.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: ata: sata_sx4: Add error handling in pdc20621_i2c_read() ata: pata_pxa: Fix potential NULL pointer dereference in pxa_ata_probe()