summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-06s390/mem_detect: add get_mem_detect_online_total()Vasily Gorbik
Add a function to get online memory in total. It is supposed to be used in the decompressor as well as during early kernel startup. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/mem_detect: handle online memory limit just onceVasily Gorbik
Introduce mem_detect_truncate() to cut any online memory ranges above established identity mapping size, so that mem_detect users wouldn't have to do it over and over again. Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/boot: fix mem_detect extended area allocationVasily Gorbik
Allocation of mem_detect extended area was not considered neither in commit 9641b8cc733f ("s390/ipl: read IPL report at early boot") nor in commit b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)"). As a result mem_detect extended theoretically may overlap with ipl report or randomized kernel image position. But as mem_detect code will allocate extended area only upon exceeding 255 online regions (which should alternate with offline memory regions) it is not seen in practice. To make sure mem_detect extended area does not overlap with ipl report or randomized kernel position extend usage of "safe_addr". Make initrd handling and mem_detect extended area allocation code move it further right and make KASLR takes in into consideration as well. Fixes: 9641b8cc733f ("s390/ipl: read IPL report at early boot") Fixes: b2d24b97b2a9 ("s390/kernel: add support for kernel address space layout randomization (KASLR)") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/mem_detect: rely on diag260() if sclp_early_get_memsize() failsVasily Gorbik
In case sclp_early_get_memsize() fails but diag260() succeeds make sure some sane value is returned. This error scenario is highly unlikely, but this change makes system able to boot in such case. Suggested-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/diag: make __diag8c_tmp_amode31 staticHeiko Carstens
Get rid of this sparse warning: arch/s390/kernel/diag.c:69:29: warning: symbol '__diag8c_tmp_amode31' was not declared. Should it be static? Fixes: fbaee7464fbb ("s390/tty3270: add support for diag 8c") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/rethook: add local rethook header fileHeiko Carstens
Compiling the kernel with CONFIG_KPROBES disabled, but CONFIG_RETHOOK enabled, results in this sparse warning: arch/s390/kernel/rethook.c:26:15: warning: no previous prototype for 'arch_rethook_trampoline_callback' [-Wmissing-prototypes] 26 | unsigned long arch_rethook_trampoline_callback(struct pt_regs *regs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add a local rethook header file similar to riscv to address this. Reported-by: kernel test robot <lkp@intel.com> Fixes: 1a280f48c0e4 ("s390/kprobes: replace kretprobe with rethook") Link: https://lore.kernel.org/all/202302030102.69dZIuJk-lkp@intel.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/vmem: remove unnecessary KASAN checksVasily Gorbik
Kasan shadow memory area has been moved to the end of kernel address space since commit 9a39abb7c9aa ("s390/boot: simplify and fix kernel memory layout setup"), therefore skipping any memory ranges above VMALLOC_START in empty page tables cleanup code already handles KASAN shadow memory intersection case and explicit checks could be removed. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/vmem: fix empty page tables cleanup under KASANVasily Gorbik
Commit b9ff81003cf1 ("s390/vmem: cleanup empty page tables") introduced empty page tables cleanup in vmem code, but when the kernel is built with KASAN enabled the code has no effect due to wrong KASAN shadow memory intersection condition, which effectively ignores any memory range below KASAN shadow. Fix intersection condition to make code work as anticipated. Fixes: b9ff81003cf1 ("s390/vmem: cleanup empty page tables") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/kasan: update kasan memory layout noteVasily Gorbik
Kasan shadow memory area has been moved to the end of kernel address space since commit 9a39abb7c9aa ("s390/boot: simplify and fix kernel memory layout setup"). Change kasan memory layout note accordingly. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/mem_detect: fix detect_memory() error handlingVasily Gorbik
Currently if for some reason sclp_early_read_info() fails, sclp_early_get_memsize() will not set max_physmem_end and it will stay uninitialized. Any garbage value other than 0 will lead to detect_memory() taking wrong path or returning a garbage value as max_physmem_end. To avoid that simply initialize max_physmem_end. Fixes: 73045a08cf55 ("s390: unify identity mapping limits handling") Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/hmcdrv: use strscpy() instead of strlcpy()Heiko Carstens
Given that strlcpy() is deprecated use strscpy() instead. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/ipl: add loadparm parameter to eckd ipl/reipl dataSven Schnelle
commit 87fd22e0ae92 ("s390/ipl: add eckd support") missed to add the loadparm attribute to the new eckd ipl/reipl data. Fixes: 87fd22e0ae92 ("s390/ipl: add eckd support") Cc: <stable@vger.kernel.org> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-02-06s390/ipl: add DEFINE_GENERIC_LOADPARM()Sven Schnelle
In the current code each reipl type implements its own pair of loadparm show/store functions. Add a macro to deduplicate the code a bit. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Fixes: 87fd22e0ae92 ("s390/ipl: add eckd support") Cc: <stable@vger.kernel.org> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-31s390/mem_detect: do not update output parameters on failureAlexander Gordeev
Function __get_mem_detect_block() resets start and end output parameters in case of invalid mem_detect array index is provided. That violates the rule of sparing the output on fail path and leads e.g to a below anomaly: for_each_mem_detect_block(i, &start, &end) continue; One would expect start and end contain addresses of the last memory block (if available), but in fact the two will be reset to zeroes. That is not how an iterator is expected to work. Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-31s390/cio: introduce locking for register/unregister functionsVineeth Vijayan
Unbinding an I/O subchannel with a child-CCW device in disconnected state sometimes causes a kernel-panic. The race condition was seen mostly during testing, when setting all the CHPIDs of a device to offline and at the same time, the unbinding the I/O subchannel driver. The kernel-panic occurs because of double delete, the I/O subchannel driver calls device_del on the CCW device while another device_del invocation for the same device is in-flight. For instance, disabling all the CHPIDs will trigger the ccw_device_remove function, which will call a ccw_device_unregister(), which ends up calling the device_del() which is asynchronous via cdev's todo workqueue. And unbinding the I/O subchannel driver calls io_subchannel_remove() function which calls the ccw_device_unregister() and device_del(). This double delete can be prevented by serializing all CCW device registration/unregistration calls into the driver core. This patch introduces a mutex which will be used for this purpose. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-31s390/mm,ptdump: avoid Kasan vs Memcpy Real markers swappingVasily Gorbik
---[ Real Memory Copy Area Start ]--- 0x001bfffffffff000-0x001c000000000000 4K PTE I ---[ Kasan Shadow Start ]--- ---[ Real Memory Copy Area End ]--- 0x001c000000000000-0x001c000200000000 8G PMD RW NX ... ---[ Kasan Shadow End ]--- ptdump does a stable sort of markers. Move kasan markers after memcpy real to avoid swapping. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-31s390/boot: remove pgtable_populate_endVasily Gorbik
setup_vmem() already calls populate for all online memory regions. pgtable_populate_end() could be removed. Also rename pgtable_populate_begin() to pgtable_populate_init(). Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-31s390/boot: avoid mapping standby memoryVasily Gorbik
Commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled") doesn't consider online memory holes due to potential memory offlining and erroneously creates pgtables for stand-by memory, which bear RW+X attribute and trigger a warning: RANGE SIZE STATE REMOVABLE BLOCK 0x0000000000000000-0x0000000c3fffffff 49G online yes 0-48 0x0000000c40000000-0x0000000c7fffffff 1G offline 49 0x0000000c80000000-0x0000000fffffffff 14G online yes 50-63 0x0000001000000000-0x00000013ffffffff 16G offline 64-79 s390/mm: Found insecure W+X mapping at address 0xc40000000 WARNING: CPU: 14 PID: 1 at arch/s390/mm/dump_pagetables.c:142 note_page+0x2cc/0x2d8 Map only online memory ranges which fit within identity mapping limit. Fixes: bb1520d581a3 ("s390/mm: start kernel with DAT enabled") Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/syscalls: get rid of system call alias functionsHeiko Carstens
bpftrace and friends only consider functions present in /sys/kernel/tracing/available_filter_functions. For system calls there is the s390 specific problem that the system call function itself is present via __se_sys##name() while the system call itself is wired up via an __s390x_sys##name() alias. The required DWARF debug information however is only available for the original function, not the alias, but within available_filter_functions only the functions with __s390x_ prefix are available. Which means the required DWARF debug information cannot be found. While this could be solved via tooling, it is easier to change the s390 specific system call wrapper handling. Therefore get rid of this alias handling and implement system call wrappers like most other architectures are doing. In result the implementation generates the following functions: long __s390x_sys##name(struct pt_regs *regs) static inline long __se_sys##name(...) static inline long __do_sys##name(...) __s390x_sys##name() is the visible system call function which is also wired up in the system call table. Its only parameter is a pt_regs variable. This function calls the corresponding __se_sys##name() function, which has as many parameters like the system call definition. This function in turn performs all zero and sign extensions of all system call parameters, taken from the pt_regs structure, and finally calls __do_sys##name(). __do_sys##name() is the actual inlined system call function implementation. For all 64 bit system calls there is a 31/32 bit system call function __s390_sys##name() generated, which handles all system call parameters correctly as required by compat handling. This function may be wired up within the compat system call table, unless there exists an explicit compat system call function, which is then used instead. Reported-by: Ilya Leoshkevich <iii@linux.ibm.com> Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/syscalls: remove trailing semicolonHeiko Carstens
Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/syscalls: move __S390_SYS_STUBx() macroHeiko Carstens
Move __S390_SYS_STUBx() the end of the CONFIG_COMPAT section, so both variants (compat and non-compat) are close together and can be easily compared. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/syscalls: remove __SC_COMPAT_TYPE defineHeiko Carstens
Remove __SC_COMPAT_TYPE define which is an unused leftover. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/syscalls: remove SYSCALL_METADATA() from compat syscallsHeiko Carstens
SYSCALL_METADATA() is only supposed to be used for non-compat system calls. Otherwise there would be a name clash. This also removes the inconsistency that s390 is the only architecture which uses SYSCALL_METADATA() for compat system calls, and even that only for compat system calls without parameters. Only two such compat system calls exist. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390: discard .interp sectionIlya Leoshkevich
When debugging vmlinux with QEMU + GDB, the following GDB error may occur: (gdb) c Continuing. Warning: Cannot insert breakpoint -1. Cannot access memory at address 0xffffffffffff95c0 Command aborted. (gdb) The reason is that, when .interp section is present, GDB tries to locate the file specified in it in memory and put a number of breakpoints there (see enable_break() function in gdb/solib-svr4.c). Sometimes GDB finds a bogus location that matches its heuristics, fails to set a breakpoint and stops. This makes further debugging impossible. The .interp section contains misleading information anyway (vmlinux does not need ld.so), so fix by discarding it. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: simplify PMC_INIT and PMC_RELEASE usageThomas Richter
Simplify the use of constants PMC_INIT and PMC_RELEASE. Suggested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: merge source files for CPU Measurement counter facilityThomas Richter
With no in-kernel user, the source files can be merged. Move all functions and the variable definitions to file perf_cpum_cf.c This file now contains all the necessary functions and definitions for the CPU Measurement counter facility device driver. The files cpu_mcf.h and perf_cpum_cf_common.c are deleted. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: remove in-kernel counting facility interfaceThomas Richter
Commit 17bebcc68eee ("s390/cpum_cf: Add minimal in-kernel interface for counter measurements") introduced a small in-kernel interface for CPU Measurement counter facility. There are no users of this interface, therefore remove it. The following functions are removed: kernel_cpumcf_alert(), kernel_cpumcf_begin(), kernel_cpumcf_end(), kernel_cpumcf_avail() there is no need for them anymore. With the removal of function kernel_cpumcf_alert(), also remove member alert in struct cpu_cf_events. Its purpose was to counter measurement alert interrupts for the in-kernel interface. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: move stccm_avail()Thomas Richter
Function stccm_avail() is defined in a header file and the only user is one single source file. Move this function to the source file where it is also used and remove it from the header file. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: move cpum_cf_ctrset_size()Thomas Richter
Function cpum_cf_ctrset_size() is defined in one source file and the only user is in another source file. Move this function to the source file where it is used and remove its prototype from the header file. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cpum_cf: simplify hw_perf_event_destroy()Thomas Richter
To remove an event from the CPU Measurement counter facility use the lock/unlock scheme as done in event creation. Remove the atomic_add_unless function to make the code easier. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-25s390/cache: change type from unsigned long long to unsigned longHeiko Carstens
The unsigned long long type is a leftover of the 31 bit area. Get rid of it. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio_ap: increase max wait time for reset verificationTony Krowiak
Increase the maximum time to wait for verification of a queue reset operation to 200ms. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-7-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio_ap: fix handling of error response codesTony Krowiak
Some response codes returned from the queue reset function are not being handled correctly; this patch fixes them: 1. Response code 3, AP queue deconfigured: Deconfiguring an AP adapter resets all of its queues, so this is handled by indicating the reset verification completed successfully. 2. For all response codes other than 0 (normal reset completion), 2 (queue reset in progress) and 3 (AP deconfigured), the -EIO error will be returned from the vfio_ap_mdev_reset_queue() function. In all cases, all fields of the status word other than the response code will be set to zero, so it makes no sense to check status bits. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-6-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio_ap: verify ZAPQ completion after return of response code zeroTony Krowiak
Verification that the asynchronous ZAPQ function has completed only needs to be done when the response code indicates the function was successfully initiated; so, let's call the apq_reset_check function immediately after the response code zero is returned from the ZAPQ. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-5-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio_ap: use TAPQ to verify reset in progress completesTony Krowiak
To eliminate the repeated calls to the PQAP(ZAPQ) function to verify that a reset in progress completed successfully and ensure that error response codes get appropriately logged, let's call the apq_reset_check() function when the ZAPQ response code indicates that a reset that is already in progress. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-4-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio_ap: check TAPQ response code when waiting for queue resetTony Krowiak
The vfio_ap_mdev_reset_queue() function does not check the status response code returned form the PQAP(TAPQ) function when verifying the queue's status; consequently, there is no way of knowing whether verification failed because the wait time was exceeded, or because the PQAP(TAPQ) failed. This patch adds a function to check the status response code from the PQAP(TAPQ) instruction and logs an appropriate message if it fails. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-3-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vfio-ap: verify reset complete in separate functionTony Krowiak
The vfio_ap_mdev_reset_queue() function contains a loop to verify that the reset successfully completes within 40ms. This patch moves that loop into a separate function. Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Link: https://lore.kernel.org/r/20230118203111.529766-2-akrowiak@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/kprobes: replace kretprobe with rethookVasily Gorbik
That's an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes: Replace kretprobe with rethook on x86") to s390. Replaces the kretprobe code with rethook on s390. With this patch, kretprobe on s390 uses the rethook instead of kretprobe specific trampoline code. Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cpum_sf: diagnostic sampling buffer setup to handle virtual addressesThomas Richter
The CPU Measurement Sampling Facility (CPUM_SF) installs large buffers to save samples collected by hardware. These buffers are organized as Sample Data Buffer Tables (SDBT) and Sample Data Buffers (SDB). SDBs contain the samples which are extracted and saved in the perf ring buffer. The SDBTs are chained using real addresses and refer to SDBs using real addresses. The diagnostic sampling setup uses buffers provided by the process which invokes perf_event_open system call. The buffers are memory mapped. The buffers have been allocated by the kernel event subsystem. Add proper virtual to phyiscal address translation to the buffer chaining. The current constraint which requires virtual equals real address layout is removed. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cpum_sf: rework macro AUX_SDB_NUM_xxxThomas Richter
Macro AUX_SDB_NUM() has three parameters. The first one is not used. Remove the first parameter. Also convert the macros to inline functions. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cpum_sf: sampling buffer setup to handle virtual addressesThomas Richter
The CPU Measurement Sampling Facility (CPUM_SF) installs large buffers to save samples collected by hardware. These buffers are organized as Sample Data Buffer Tables (SDBT) and Sample Data Buffers (SDB). SDBs contain the samples which are extracted and saved in the perf ring buffer. The SDBTs are chained using real addresses and refer to SDBs using real addresses. Adds proper virtual to phyiscal address translation to the buffer chaining. The current constraint which requires virtual equals real address layout is removed. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cpum_sf: remove debug statements from function setup_pmc_cpuThomas Richter
Remove debug statements from function setup_pmc_cpu(). The debug statement displays a pointer value to a per cpu variable. This pointer value is printed nowhere else, so it has no use for cross reference. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cpum_sf: move functions from header file to source fileThomas Richter
Some inline helper functions are defined in a header file but used in only one source file. Move these functions to the source file. No functional change. Signed-off-by: Thomas Richter <tmricht@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/vmem: use swap() instead of open coding itJiapeng Chong
Swap is a function interface that provides exchange function. To avoid code duplication, we can use swap function. ./arch/s390/mm/vmem.c:680:10-11: WARNING opportunity for swap(). [hca@linux.ibm.com: get rid of all temp variables] Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3786 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20230117060223.58583-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/cio: evaluate devices with non-operational pathsVineeth Vijayan
css_schedule_reprobe() function calls the evaluation for CSS_EVAL_UNREG which is specific to the idset of unregistered subchannels. This evaluation was introduced because, previously, if the underlying device become not-accessible, the subchannel was unregistered. But, in the recent changes in cio,with the commit '2297791c92d0 s390/cio: dont unregister subchannel from child-drivers', we no longer unregister the subchannels just because of a non-operational device. This allows to have subchannels without any operational device connected on it. So, a css_schedule_reprobe function on unregistered subchannel does not have any effect. Change this functionality to evaluate the subchannels which does not have a working path to the device. This could be due the erroneous device or due to the erraneous path. Evaluate based on the values of OPM and PAM&POM. Here we introduced a new idset function,to keep I/O subchannels in the idset when the last seen status indicates that the device has no working path. A device has no working path if all available paths have been tried without success.A failed I/O attempt on a path is indicated as a 0 bit value in the POM mask. By looking at the POM mask bit values of available paths (1 in PAM) that Linux is supposed to use (1 in vary mask OPM), we can identify a non-working device as a device where the bit-wise and of the PAM, POM and OPM mask return 0. css_schedule_reprobe() is being used by dasd-driver and chsc-cio component. dasd driver, when it detects a change in the pathgroup, invokes the re-evaluation of the subchannel. And chsc-cio component upon a CRW event, (resource accessibility event). In both the cases, it makes much better sense to re-evalute the subchannel with no-valid path. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reported-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-22s390/ipl: use kstrtobool() instead of strtobool()Christophe JAILLET
strtobool() is the same as kstrtobool(). However, the latter is more used within the kernel. In order to remove strtobool() and slightly simplify kstrtox.h, switch to the other function name. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/58a3ed2e21903a93dfd742943b1e6936863ca037.1673708887.git.christophe.jaillet@wanadoo.fr Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-17Merge branch 'fixes' into featuresHeiko Carstens
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-17s390: workaround invalid gcc-11 out of bounds read warningHeiko Carstens
GCC 11.1.0 and 11.2.0 generate a wrong warning when compiling the kernel e.g. with allmodconfig: arch/s390/kernel/setup.c: In function ‘setup_lowcore_dat_on’: ./include/linux/fortify-string.h:57:33: error: ‘__builtin_memcpy’ reading 128 bytes from a region of size 0 [-Werror=stringop-overread] ... arch/s390/kernel/setup.c:526:9: note: in expansion of macro ‘memcpy’ 526 | memcpy(abs_lc->cregs_save_area, S390_lowcore.cregs_save_area, | ^~~~~~ This could be addressed by using absolute_pointer() with the S390_lowcore macro, but this is not a good idea since this generates worse code for performance critical paths. Therefore simply use a for loop to copy the array in question and get rid of the warning. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-13docs/ABI: use linux-s390 list as the main contactVineeth Vijayan
Remove Cornelia's email address from the file as suggested by her. List linux-s390 mailing-list address as the primary contact instead. Link: https://lore.kernel.org/linux-s390/8735d0oiq6.fsf@redhat.com/ Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2023-01-13s390/vfio-ap: fix an error handling path in vfio_ap_mdev_probe_queue()Christophe JAILLET
The commit in Fixes: has switch the order of a sysfs_create_group() and a kzalloc(). It correctly removed the now useless kfree() but forgot to add a sysfs_remove_group() in case of (unlikely) memory allocation failure. Add it now. Fixes: 260f3ea14138 ("s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Link: https://lore.kernel.org/r/d0c0a35eec4fa87cb7f3910d8ac4dc0f7dc9008a.1659283738.git.christophe.jaillet@wanadoo.fr Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
generated by cgit (git 2.34.1) at 2025-06-05 17:25:30 +0000