aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-04-21s390/disassembler: increase ebpf disasm buffer sizeVasily Gorbik1-1/+1
Current ebpf disassembly buffer size of 64 is too small. E.g. this line takes 65 bytes: 01fffff8005822e: ec8100ed8065\tclgrj\t%r8,%r1,8,001fffff80058408\n\0 Double the buffer size like it is done for the kernel disassembly buffer. Fixes the following KASAN finding: UG: KASAN: stack-out-of-bounds in print_fn_code+0x34c/0x380 Write of size 1 at addr 001fff800ad5f970 by task test_progs/853 CPU: 53 PID: 853 Comm: test_progs Not tainted 5.12.0-rc7-23786-g23457d86b1f0-dirty #19 Hardware name: IBM 3906 M04 704 (LPAR) Call Trace: [<0000000cd8e0538a>] show_stack+0x17a/0x1668 [<0000000cd8e2a5d8>] dump_stack+0x140/0x1b8 [<0000000cd8e16e74>] print_address_description.constprop.0+0x54/0x260 [<0000000cd75a8698>] kasan_report+0xc8/0x130 [<0000000cd6e26da4>] print_fn_code+0x34c/0x380 [<0000000cd6ea0f4e>] bpf_int_jit_compile+0xe3e/0xe58 [<0000000cd72c4c88>] bpf_prog_select_runtime+0x5b8/0x9c0 [<0000000cd72d1bf8>] bpf_prog_load+0xa78/0x19c0 [<0000000cd72d7ad6>] __do_sys_bpf.part.0+0x18e/0x768 [<0000000cd6e0f392>] do_syscall+0x12a/0x220 [<0000000cd8e333f8>] __do_syscall+0x98/0xc8 [<0000000cd8e54834>] system_call+0x6c/0x94 1 lock held by test_progs/853: #0: 0000000cd9bf7460 (report_lock){....}-{2:2}, at: kasan_report+0x96/0x130 addr 001fff800ad5f970 is located in stack of task test_progs/853 at offset 96 in frame: print_fn_code+0x0/0x380 this frame has 1 object: [32, 96) 'buffer' Memory state around the buggy address: 001fff800ad5f800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >001fff800ad5f900: 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 f3 f3 ^ 001fff800ad5f980: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 001fff800ad5fa00: 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 Cc: <stable@vger.kernel.org> Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-21s390/archrandom: add parameter check for s390_arch_random_generateHarald Freudenberger1-0/+4
A review of the code showed, that this function which is exposed within the whole kernel should do a parameter check for the amount of bytes requested. If this requested bytes is too high an unsigned int overflow could happen causing this function to try to memcpy a really big memory chunk. This is not a security issue as there are only two invocations of this function from arch/s390/include/asm/archrandom.h and both are not exposed to userland. Reported-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-21s390/zcrypt: fix zcard and zqueue hot-unplug memleakHarald Freudenberger2-0/+2
Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object. Fixes: 29c2680fd2bf ("s390/ap: fix ap devices reference counting") Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Cc: stable@vger.kernel.org Reviewed-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-20s390/pci: expose a PCI device's UID as its indexNiklas Schnelle2-4/+42
On s390 each PCI device has a user-defined ID (UID) exposed under /sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI device's primary index and to match the device within Linux to the device configured in the hypervisor. To serve as a primary identifier the UID must be unique within the Linux instance, this is guaranteed by the platform if and only if the UID Uniqueness Checking flag is set within the CLP List PCI Functions response. In this sense the UID serves an analogous function as the SMBIOS instance number or ACPI index exposed as the "index" respectively "acpi_index" device attributes and used by e.g. systemd to set interface names. As s390 does not use and will likely never use ACPI nor SMBIOS there is no conflict and we can just expose the UID under the "index" attribute whenever UID Uniqueness Checking is active and get systemd's interface naming support for free. Link: https://lore.kernel.org/lkml/20210412135905.1434249-1-schnelle@linux.ibm.com/ Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Narendra K <narendra_k@dell.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-18s390/atomic,cmpxchg: always inline __xchg/__cmpxchgHeiko Carstens1-3/+5
Make sure to always inline __xchg() and __cmpxchg() otherwise the compiler might decide to generate out-of-line versions which will fail at link time: s390-linux-ld: lib/atomic64_test.o: in function `__xchg': >> atomic64_test.c:(.text.unlikely+0xa4): undefined reference to `__xchg_called_with_bad_pointer' Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/linux-mm/202104170449.SIIFKVjT-lkp@intel.com/ Fixes: d2b1f6d2d350 ("s390/cmpxchg: get rid of gcc atomic builtins") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-18s390/smp: fix do_restart() prototypeAlexander Gordeev2-3/+3
Funciton do_restart() is a callback invoked from the restart CPU routine and passed a single parameter. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-18s390: get rid of oprofile leftoversMarc Zyngier1-21/+0
perf_pmu_name() and perf_num_counters() are unused. Drop them. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210414134409.1266357-4-maz@kernel.org Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-15s390/atomic,cmpxchg: make constraints work with old compilersHeiko Carstens2-9/+9
Old gcc versions may fail with an internal compiler error if only the T or S constraint is specified for an operand, and no displacement is needed at all. To fix this use RT and QS as constraints, which reflects the union of both. Later gcc versions do the right thing and always accept single T and S constraints. See gcc commit 3e4be43f69da ("S/390: Memory constraint cleanup"). Fixes: ca897bb1814f ("s390/atomic: use proper constraints") Fixes: b23eb636d7f9 ("s390/atomic: get rid of gcc atomic builtins") Fixes: d2b1f6d2d350 ("s390/cmpxchg: get rid of gcc atomic builtins") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-15s390/test_unwind: print test suite start/end infoVasily Gorbik1-1/+7
Add couple of additional info lines to make it easier to match test suite output and results. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-15s390/cmpxchg: use unsigned long values instead of void pointersHeiko Carstens1-26/+23
gcc and clang warn about incompatible pointer types due to the recent cmpxchg changes: drivers/gpu/drm/drm_lock.c:75:10: error: passing 'typeof (lock)' (aka 'volatile unsigned int *') to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] prev = cmpxchg(lock, old, new); ^~~~~~~~~~~~~~~~~~~~~~~ include/asm-generic/atomic-instrumented.h:1685:2: note: expanded from macro 'cmpxchg' arch_cmpxchg(__ai_ptr, __VA_ARGS__); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To avoid this simply cast pointers to unsigned long and use them instead of void pointers. This allows to stay with functions, instead of using complex defines and having to deal with all their potential side effects. Reported-by: kernel test robot <lkp@intel.com> Fixes: d2b1f6d2d350 ("s390/cmpxchg: get rid of gcc atomic builtins") Link: https://lore.kernel.org/linux-s390/202104130131.sMmSqpb5-lkp@intel.com/ Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/test_unwind: add WARN if tests failedVasily Gorbik1-3/+6
Trigger a warning if any of unwinder tests fail. This should help to prevent quiet ignoring of test results when panic_on_warn is enabled. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/test_unwind: unify error handling pathsVasily Gorbik1-2/+2
Handle the case of "unwind state reliable but addr is 0" like other error cases in this function and trigger output of failing stacktrace to aid debugging. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390: update defconfigsHeiko Carstens2-2/+0
Set CONFIG_FRAME_WARN to 2048, which is the default for 64 bit architectures. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/spinlock: use R constraint in inline assemblyHeiko Carstens1-1/+1
Allow the compiler to generate slightly better code by using the R constraint. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/atomic,cmpxchg: switch to use atomic-instrumented.hHeiko Carstens2-30/+58
Add arch_ prefix to all atomic operations, and define ARCH_ATOMIC. This enables KASAN instrumentation for all atomic operations on s390. This is the s390 variant of commit 8bf705d13039 ("locking/atomic/x86: Switch atomic.h to use atomic-instrumented.h"). Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/cmpxchg: get rid of gcc atomic builtinsHeiko Carstens1-15/+150
s390 is the only architecture in the kernel which makes use of gcc's atomic builtin functions. Even though I don't see any technical problem with that right now, remove this code and open-code compare-and-swap loops again, like every other architecture is doing it also. We can switch to a generic implementation when other architectures are doing that also. See also https://lwn.net/Articles/586838/ for forther details. This basically reverts commit f318a1229bd8 ("s390/cmpxchg: use compiler builtins"). Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/atomic: get rid of gcc atomic builtinsHeiko Carstens1-6/+30
s390 is the only architecture in the kernel which makes use of gcc's atomic builtin functions. Even though I don't see any technical problem with that right now, remove this code and open-code compare-and-swap loops again, like every other architecture is doing it also. We can switch to a generic implementation when other architectures are doing that also. See also https://lwn.net/Articles/586838/ for forther details. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/atomic: use proper constraintsHeiko Carstens1-7/+7
Use the R,T, and S constraints instead of the Q constraint in atomic inline assemblies wherever possible. This allows the compiler to generate better code. (~ -2kb code size). Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/atomic: move remaining inline assemblies to atomic_ops.hHeiko Carstens2-18/+38
Move all remaining inline assemblies from atomic.h to atomic_ops.h. That way all atomic inline assemblies are contained within only a single header file. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/bitops: make bitops only work on longsHeiko Carstens1-46/+47
The bitops code was optimized to generate test under mask instructions with the __bitops_byte() helper. However that was many years ago and in the meantime a lot of new instructions were introduced. Changing the code so that it always operates on longs nowadays even generates shorter code (~ -20kb, defconfig, gcc 10, march=zE12). Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/traps,mm: add conditional trap handlersHeiko Carstens3-18/+12
Add conditional trap handlers similar to conditional system calls (COND_SYSCALL), to reduce the number of ifdefs. Trap handlers which may or may not exist depending on config options are supposed to have a COND_TRAP entry, which redirects to default_trap_handler() for non-existent trap handlers during link time. This allows to get rid of the secure execution trap handlers for the !PGSTE case. Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: narrow scope of zpci_configure_device()Niklas Schnelle2-12/+10
Currently zpci_configure_device() can be called on a zPCI function in two completely different states. Either the underlying zPCI function has already been configured by the platform and we are only doing the scanning to get it usable by Linux drivers. Or the underlying function is in Standby and we first do an SCLP to get it configured. This makes zpci_configure_device() harder to reason about. Since calling zpci_configure_device() on a function in Standby only happens in enable_slot() simply pull out the SCLP call and setting of zdev->state and thus call zpci_configure_device() under the same circumstances as in the event handling code. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: separate zbus registration from scanningNiklas Schnelle5-30/+33
Now that the zbus can be created without being scanned we can go one step further and make registering a device to a zbus independent from scanning it. This way the zbus handling becomes much more natural in that functions can be registered on the zbus to be scanned later more closely resembling the handling of both real PCI hardware and other virtual PCI busses like Hyper-V's virtual PCI bus (see for example drivers/pci/controller/pci-hyperv.c:create_root_hv_pci_bus()). Having zbus registration separate from scanning allows us to return fully initialized but still disabled zdevs from zpci_create_device() which can then be configured just as we would configure a zdev from standby (minus the SCLP Configure already done by the platform). There is still the exception that a PCI function with non-zero devfn can be plugged before its PCI bus, which depends on the function with zero devfn, is created. In this case the zdev returend from zpci_create_device() is still missing its bus, hotplug slot, and resources which need to be created later but at least it doesn't wait in the enabled state and can otherwise be treated as initialized. With this we also separate the initial PCI scan using CLP List PCI Functions into two phases. In the CLP loop's callback we only register each function with a virtual zbus creating the latter as needed. Then, after we have built this virtual PCI topology based on our list of zbusses, we can make use of the common code functionality to scan each complete zbus as a separate child bus. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: use mutex not spinlock for zbus listNiklas Schnelle1-7/+7
In a later change we will first collect all PCI functions from the CLP List PCI functions call, then register them to/creating the relevant zbus. Then only after we've created our virtual bus structure will we scan all zbusses iterating over the zbus list. Since scanning is relatively slow a spinlock is a bad fit for protecting the loop over the devices on the zbus. Furthermore doing the probing on the bus we need to use pci_lock_rescan_remove() as devices are added to the PCI subsystem and that is a mutex which can't be locked nested inside a spinlock section. Note that the contention of this lock should be very low either way as zbusses are only added/removed concurrently on hotplug events. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: separate zbus creation from scanningNiklas Schnelle4-97/+177
In the existing code the creation of the PCI bus and the scanning of function zero all happens in zpci_scan_bus(). This in turn requires functions to be enabled and their resources to be available before the PCI bus is even created. This not only means that functions are enabled long before they are actually made available to the common PCI subsystem. In case of functions with non-zero devfn which appeared before the function with devfn zero they can wait arbitrarily long in this enabled but not scanned state. Fix this by separating the creation of the PCI bus from scanning it and only prepare, that is enable and setup MMIO bus resources, functions just before they are scanned. As they may be scanned multiple times track if we already created resources in the zdev. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: do more bus setup in zpci_bus_scan()Niklas Schnelle1-13/+20
Pull setting the maximum bus speed and multifunction attribute into zpci_bus_scan() in preparation for handling bus creation separately from scanning the bus. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/pci: introduce zpci_bus_scan_device()Niklas Schnelle3-17/+28
To match zpci_bus_scan_device() and the PCI common code terminology and to remove some code duplication, we pull the multiple uses of pci_scan_single_device() into a function. For now this has the side effect of adding each device to the PCI bus separately and locking and unlocking the rescan/remove lock for each instead of just once per bus. This is clearly less efficient but provides a correct intermediate behavior until a follow on change does both the adding and scanning only once per bus. Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/traps: convert pgm_check.S to CHeiko Carstens5-181/+59
Convert the program check table to C. Which allows to get rid of yet another assembler file, and also enables proper type checking for the table. Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/cio: use DECLARE_WAIT_QUEUE_HEAD for static work_queue_head_tVineeth Vijayan1-2/+1
Use DECLARE_WAIT_QUEUE_HEAD to declare and statically initialize the work_queue_head_t. Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/protvirt: fix error return code in uv_info_init()zhongbaisong1-1/+3
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com> Fixes: 37564ed834ac ("s390/uv: add prot virt guest/host indication files") Link: https://lore.kernel.org/r/2f7d62a4-3e75-b2b4-951b-75ef8ef59d16@huawei.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12Merge branch 'fixes' into featuresHeiko Carstens9-13/+33
* fixes: s390/entry: save the caller of psw_idle s390/entry: avoid setting up backchain in ext|io handlers s390/setup: use memblock_free_late() to free old stack s390/irq: fix reading of ext_params2 field from lowcore s390/unwind: add machine check handler stack s390/cpcmd: fix inline assembly register clobbering MAINTAINERS: add backups for s390 vfio drivers s390/vdso: fix initializing and updating of vdso_data s390/vdso: fix tod_steering_delta type s390/vdso: copy tod_steering_delta value to vdso_data page Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/entry: save the caller of psw_idleVasily Gorbik1-0/+1
Currently psw_idle does not allocate a stack frame and does not save its r14 and r15 into the save area. Even though this is valid from call ABI point of view, because psw_idle does not make any calls explicitly, in reality psw_idle is an entry point for controlled transition into serving interrupts. So, in practice, psw_idle stack frame is analyzed during stack unwinding. Depending on build options that r14 slot in the save area of psw_idle might either contain a value saved by previous sibling call or complete garbage. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs ([task 0000038000003dd8] 0x0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 So, to make a stacktrace nicer and actually point for the real caller of psw_idle in this frequently occurring case, make psw_idle save its r14. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs ([task 0000038000003dd8] arch_cpu_idle+0x3c/0xd0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-12s390/entry: avoid setting up backchain in ext|io handlersVasily Gorbik1-4/+2
Currently when interrupt arrives to cpu while in kernel context INT_HANDLER macro (used for ext_int_handler and io_int_handler) allocates new stack frame and pt_regs on the kernel stack and sets up the backchain to jump over the pt_regs to the frame which has been interrupted. This is not ideal to two reasons: 1. This hides the fact that kernel stack contains interrupt frame in it and hence breaks arch_stack_walk_reliable(), which needs to know that to guarantee "reliability" and checks that there are no pt_regs on the way. 2. It breaks the backchain unwinder logic, which assumes that the next stack frame after an interrupt frame is reliable, while it is not. In some cases (when r14 contains garbage) this leads to early unwinding termination with an error, instead of marking frame as unreliable and continuing. To address that, only set backchain to 0. Fixes: 56e62a737028 ("s390: convert to generic entry") Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390/sclp: use LIST_HEAD for InitializationVineeth Vijayan4-16/+8
For static initialization of list_head variable, use LIST_HEAD instead of INIT_LIST_HEAD function. Suggested-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390: use DEFINE_SPINLOCK for initializationVineeth Vijayan4-8/+4
For static initialization of spinlock_t variable, use DEFINE_SPINLOCK instead of explicitly calling spin_lock_init(). Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-07s390/setup: use memblock_free_late() to free old stackHeiko Carstens1-1/+1
Use memblock_free_late() to free the old machine check stack to the buddy allocator instead of leaking it. Fixes: b61b1595124a ("s390: add stack for machine check handler") Cc: Vasily Gorbik <gor@linux.ibm.com> Acked-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/mm: fix phys vs virt confusion in mark_kernel_pXd() functions familyAlexander Gordeev1-4/+4
Due to historical reasons mark_kernel_pXd() functions misuse the notion of physical vs virtual addresses difference. Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/vfio-ap: fix circular lockdep when setting/clearing crypto masksTony Krowiak2-95/+215
This patch fixes a lockdep splat introduced by commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated"). The lockdep splat only occurs when starting a Secure Execution guest. Crypto virtualization (vfio_ap) is not yet supported for SE guests; however, in order to avoid this problem when support becomes available, this fix is being provided. The circular locking dependency was introduced when the setting of the masks in the guest's APCB was executed while holding the matrix_dev->lock. While the lock is definitely needed to protect the setting/unsetting of the matrix_mdev->kvm pointer, it is not necessarily critical for setting the masks; so, the matrix_dev->lock will be released while the masks are being set or cleared. Keep in mind, however, that another process that takes the matrix_dev->lock can get control while the masks in the guest's APCB are being set or cleared as a result of the driver being notified that the KVM pointer has been set or unset. This could result in invalid access to the matrix_mdev->kvm pointer by the intervening process. To avoid this scenario, two new fields are being added to the ap_matrix_mdev struct: struct ap_matrix_mdev { ... bool kvm_busy; wait_queue_head_t wait_for_kvm; ... }; The functions that handle notification that the KVM pointer value has been set or cleared will set the kvm_busy flag to true until they are done processing at which time they will set it to false and wake up the tasks on the matrix_mdev->wait_for_kvm wait queue. Functions that require access to matrix_mdev->kvm will sleep on the wait queue until they are awakened at which time they can safely access the matrix_mdev->kvm field. Fixes: f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated") Cc: stable@vger.kernel.org Signed-off-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: remove duplicate struct ccw1 declarationWan Jiabing1-3/+0
struct ccw1 is declared twice. One has been declared at 21st line. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: use DECLARE_WAIT_QUEUE_HEAD() for wait_queueShixin Liu1-2/+1
wait_queue_head_t can be initialized automatically with DECLARE_WAIT_QUEUE_HEAD() rather than explicitly calling init_waitqueue_head(). Signed-off-by: Shixin Liu <liushixin2@huawei.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cio: use DEFINE_SPINLOCK() for spinlockShixin Liu1-2/+1
static spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by: Shixin Liu <liushixin2@huawei.com> Acked-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/pci: expose UID uniqueness guaranteeNiklas Schnelle2-3/+20
On s390 each PCI device has a user-defined ID (UID) exposed under /sys/bus/pci/devices/<dev>/uid. This ID was designed to serve as the PCI device's primary index and to match the device within Linux to the device configured in the hypervisor. To serve as a primary identifier the UID must be unique within the Linux instance, this is guaranteed by the platform if and only if the UID Uniqueness Checking flag is set within the CLP List PCI Functions response. While the UID has been exposed to userspace since commit ac4995b9d570 ("s390/pci: add some new arch specific pci attributes") whether or not the platform guarantees its uniqueness for the lifetime of the Linux instance while defined is not visible from userspace. Remedy this by exposing this as a per device attribute at /sys/bus/pci/devices/<dev>/uid_is_unique Keeping this a per device attribute allows for maximum flexibility if we ever end up with some devices not having a UID or not enjoying the guaranteed uniqueness. Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Viktor Mihajlovski <mihajlov@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/irq: fix reading of ext_params2 field from lowcoreHeiko Carstens1-1/+1
The contents of the ext_params2 field of the lowcore should just be copied to the pt_regs structure, not dereferenced. Fixes crashes / program check loops like this: Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0 0000000080030000 000000000000000f 0000000000000000 0000000000000000 0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518 0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428 Krnl Code: 00000000d6d02b2e: 58100080 l %r1,128 00000000d6d02b32: 5010b0a4 st %r1,164(%r11) #00000000d6d02b36: e31001b80104 lg %r1,4536 >00000000d6d02b3c: e31010000004 lg %r1,0(%r1) 00000000d6d02b42: e310b0a80024 stg %r1,168(%r11) 00000000d6d02b48: c01000242270 larl %r1,00000000d7187028 00000000d6d02b4e: d5071000b010 clc 0(8,%r1),16(%r11) 00000000d6d02b54: a784001b brc 8,00000000d6d02b8a Call Trace: [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<00000000d621d266>] die+0x106/0x188 [<00000000d62305b8>] do_no_context+0xc8/0x100 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<00000000d621d266>] die+0x106/0x188 [<00000000d62305b8>] do_no_context+0xc8/0x100 [<00000000d6d02790>] __do_pgm_check+0xe0/0x1f0 [<00000000d6d0e950>] pgm_check_handler+0x118/0x160 [<00000000d6d02b3c>] do_ext_irq+0x74/0x170 [<00000000d6d0ea5c>] ext_int_handler+0xc4/0xf4 [<0000000000000000>] 0x0 [<00000000d6d0e57a>] default_idle_call+0x42/0x110 [<00000000d629856e>] do_idle+0xce/0x160 [<00000000d62987be>] cpu_startup_entry+0x36/0x40 [<00000000d621f2f2>] smp_start_secondary+0x82/0x88 Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/unwind: add machine check handler stackVasily Gorbik2-1/+12
Fixes: b61b1595124a ("s390: add stack for machine check handler") Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-04-05s390/cpcmd: fix inline assembly register clobberingAlexander Gordeev1-2/+4
Register variables initialized using arithmetic. That leads to kasan instrumentaton code corrupting the registers contents. Follow GCC guidlines and use temporary variables for assigning init values to register variables. Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.") Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28s390/pci: fix DMA cleanup on hard deconfigureNiklas Schnelle1-6/+5
In commit dee60c0dbc83 ("s390/pci: add zpci_event_hard_deconfigured()") we added a zdev_enabled() check to what was previously an uncoditional call to zpci_disable_device(). There are two problems with that. Firstly zpci_had_deconfigured() is only called on event 0x0304 for which the device is always already disabled by the platform so it is always false. Secondly zpci_disable_device() not only disables the device but also calls zpci_dma_exit_device() which is thus not called and we leak the DMA tables. Fix this by calling zpci_disable_device() unconditionally to perform Linux side cleanup including the freeing of DMA tables. Fixes: dee60c0dbc83 ("s390/pci: add zpci_event_hard_deconfigured()") Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28s390/spinlock: remove align attribute from arch_spinlock_tHeiko Carstens1-1/+1
No need to add an align attribute for an integer. The alignment is correct anyway. Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-28MAINTAINERS: add backups for s390 vfio driversMatthew Rosato1-1/+3
Add a backup for s390 vfio-pci, an additional backup for vfio-ccw and replace the backup for vfio-ap as Pierre is focusing on other areas. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Eric Farman <farman@linux.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Acked-by: Pierre Morel <pmorel@linux.ibm.com> Acked-by: Jason J. Herne <jjherne@linux.ibm.com> Link: https://lore.kernel.org/r/1616679712-7139-1-git-send-email-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: fix initializing and updating of vdso_dataHeiko Carstens1-3/+8
Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns incorrect values when time is provided via vdso instead of system call: vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507 sys_ts_nsec = 1446923235377, sys_ts.tv_sec = 1446, sys_ts.tv_nsec = 923235377 Within the s390 specific vdso function __arch_get_hw_counter() reads tod clock steering values from the arch_data member of the passed in vdso_data structure. Problem is that only for the CS_HRES_COARSE vdso_data arch_data is initialized and gets updated. The CS_RAW specific vdso_data does not contain any valid tod_clock_steering information, which explains the different values. Fix this by initializing and updating all vdso_datas. Reported-by: Li Wang <liwang@redhat.com> Tested-by: Li Wang <liwang@redhat.com> Fixes: 1ba2d6c0fd4e ("s390/vdso: simplify __arch_get_hw_counter()") Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-03-25s390/vdso: fix tod_steering_delta typeHeiko Carstens1-1/+1
The s390 specific vdso function __arch_get_hw_counter() is supposed to consider tod clock steering. If a tod clock steering event happens and the tod clock is set to a new value __arch_get_hw_counter() will not return the real tod clock value but slowly drift it from the old delta until the returned value finally matches the real tod clock value again. Unfortunately the type of tod_steering_delta unsigned while it is supposed to be signed. It depends on if tod_steering_delta is negative or positive in which direction the vdso code drifts the clock value. Worst case is now that instead of drifting the clock slowly it will jump into the opposite direction by a factor of two. Fix this by simply making tod_steering_delta signed. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Cc: <stable@vger.kernel.org> # 5.10 Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Powered by cgit, Gruvboxed by Blaster4385.