- Feb 09, 2021
-
-
Heiko Carstens authored
Implement generic vdso time namespace support which also enables time namespaces for s390. This is quite similar to what arm64 has. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Use the passed in vdso_data pointer instead of calculating it again. This is also required as a prerequisite for vdso time namespaces: if a process is part of a time namespace __arch_get_vdso_data() will return a pointer to the time namespace data page instead of the vdso data page, which is not what __arch_get_hw_counter() expects. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
For consistency with x86 and arm64 move the data page before code pages. Similar to commit 601255ae ("arm64: vdso: move data page before code pages"). Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Add a separate "[vvar]" mapping for the vdso datapage, since it doesn't need to be executable or COW-able. This is actually the s390 implementation of commit 87154938 ("arm64: vdso: put vdso datapage in a separate vma") Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Implement vdso mapping similar to arm64 and powerpc. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
- remove unneeded includes - move functions around - remove obvious and/or incorrect comments - shorten some if conditions No functional change. Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
A few local variables exist only so the contents of a global variable can be copied to them, and use that value only for reading. Just remove them and rename some global variables. Also change vdso64_[start|end] to be character arrays to be consistent with other architectures, and get rid of the global variable vdso64_kbase. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
vdso_pages (aka vdso64_pages) is never 0, therefore remove the check. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Handle allocation error gracefully and simply disable vdso instead of leaving the system in an undefined state. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
The vdso is (and must) be page aligned and its size must also be a multiple of PAGE_SIZE. Therefore no need to round upwards. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Convert vdso_init() to arch_initcall like it is on all other architectures. This requires to remove the vdso_getcpu_init() call from vdso_init() since it must be called before smp is enabled. vdso_getcpu_init() is now an early_initcall like on powerpc. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
The vdso data page actually contains an array. Fix that. This doesn't fix a real bug, just reflects reality. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Halil Pasic authored
Since Fedora 33 the virtualization stack of Fedora requires a couple of netfilter modules to function properly. Let's add these to defconfig and debug_defconfig. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reported-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Tested-by:
Bjoern Walk <bwalk@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Marc Hartmayer authored
...but set it to off by default. Use the kernel command line option `kmemleak=on` to enable it. Signed-off-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Jan Höppner authored
The GitHub organisation name under which the s390-tools package is being hosted has changed. Update the web link. Signed-off-by:
Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Harald Freudenberger authored
When a msg is retried because the lower ap layer returns -EAGAIN there is a retry limit (currently 10). When this limit is reached the last return code from the lower layer is returned, causing the userspace to get -1 on the ioctl with errno EAGAIN. This EAGAIN is misleading here. After 10 retry attempts the userspace should receive a clear failure indication like EINVAL or EIO or ENODEV. However, the reason why these retries all fail is unclear. On an invalid message EINVAL would be returned by the lower layer, and if devices go away or are not available an ENODEV is seen. So this patch now reworks the retry loops to return EIO to userspace when the retry limit is reached. Fixes: 91ffc519 ("s390/zcrypt: introduce msg tracking in zcrypt functions") Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Alexander Egorenkov authored
Add missing forward declaration for task_struct. The warning appears when the -Werror C compiler flag is being used. Signed-off-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Acked-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Alexander Egorenkov authored
Disable CONFIG_TMPFS_INODE64 which is currently broken on s390x because size of ino_t on s390x is 4 bytes. This fixes the following error with kdump: [ 9.415082] [608]: Remounting '/' read-only in with options 'size=238372k,nr_inodes=59593,inode64'. [ 9.415093] rootfs: Cannot use inode64 with <64bit inums in kernel [ 9.415093] [ 9.415100] [608]: Failed to remount '/' read-only: Invalid argument Fixes: 5c60ed28 ("s390: update defconfigs") Signed-off-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./arch/s390/include/asm/scsw.h:528:48-50: WARNING !A || A && B is equivalent to !A || B. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Reviewed-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Chengyang Fan authored
Remove a superfluous semicolon after function definition. Signed-off-by:
Chengyang Fan <cy.fan@huawei.com> Message-Id: <20210125095839.1720265-1-cy.fan@huawei.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Niklas Schnelle authored
Currently zpci_create_device() is only called in clp_add_pci_device() which allocates the memory for the struct zpci_dev being created. There is little separation of concerns as only both functions together can create a zpci_dev and the only CLP specific code in clp_add_pci_device() is a call to clp_query_pci_fn(). Improve this by removing clp_add_pci_device() and refactor zpci_create_device() such that it alone creates and initializes the zpci_dev given the FID and Function Handle. For this we need to make clp_query_pci_fn() non-static. While at it remove the function handle parameter since we can just take that from the zpci_dev. Also move adding to the zpci_list to after the zdev has been fully created which eliminates a window where a partially initialized zdev can be found by get_zdev_by_fid(). Acked-by:
Pierre Morel <pmorel@linux.ibm.com> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
We currently track the time of the most recent QDIO Adapter Interrupt. This is a system-wide timestamp (as such interrupts are not bound to one specific qdio device). If interrupt processing stalls on one device but is functional for a different device, the timestamp continues to be updated and is of no help for problem diagnosis. So for debugging purposes also track the time of the last Data IRQ on a per-device level. Collect this data in the legacy non-AI path as well. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
tiqdio_add_device() adds the device to the tiq_list of eligible targets for a data IRQ, which gets walked on each QDIO Adapter Interrupt to inspect their DSCIs. But currently the tiqdio_add_device() / tiqdio_remove_device() calls are not symmetric - the device is removed within qdio_shutdown(), but only added by qdio_activate(). So depending on the call sequence and encountered errors, we might be trying to remove a list entry in qdio_shutdown() that was never even added to the list. This required additional INIT_LIST_HEAD() calls to ensure that the list entry was always in a consistent state. All drivers now fence the IRQ delivery via qdio_start_irq() / qdio_stop_irq(), so we can nicely integrate this tiq_list management with the other steps needed for QDIO Adapter IRQ (de-)registration (qdio_establish_thinint() / qdio_shutdown_thinint()). As the naming suggests these get called during qdio_establish() and qdio_shutdown(), with proper symmetry and roll-back after errors. With this we longer need to worry about misplaced list removals, and thus can clean up the list API abuse (INIT_LIST_HEAD() should not be called on list entries). Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
Convert the Output Queue tasklet code to take a tasklet_struct as parameter. Then initialize the tasklet with tasklet_setup() to indicate that we follow the new model. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
It's used in just one place, inline it. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
Both qeth and zfcp have fully moved to the polling-driven flow for Input Queues with commit 0a6e6345 ("s390/qdio: extend polling support to multiple queues") and commit 0b524abc ("scsi: zfcp: Lift Input Queue tasklet from qdio"). So remove the tasklet code for Input Queues, streamline the IRQ handlers and push the tasklet struct into struct qdio_output_q. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
- Jan 27, 2021
-
-
Harald Freudenberger authored
A master key change on a CCA card may cause an immediately following request to derive an protected key from a secure key to fail with error condition 8/2290. The recommendation from firmware is to retry with 1 second sleep. So now the low level cca functions return -EAGAIN when this error condition is seen and the paes retry function will evaluate the return value. Seeing EAGAIN and running in process context results in trying to sleep for 1 s now. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Reviewed-by:
Ingo Franzki <ifranzki@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Niklas Schnelle authored
Checking zdev->zbus for NULL in __zpci_event_availability() is superfluous as it can never be NULL at this point. While harmless this check causes smatch warnings because we later access zdev->zbus with only having checked zdev != NULL which is sufficient. The reason zdev->zbus can never be NULL is since with zdev != NULL given we know the zdev came from get_zdev_by_fid() and thus the zpci_list. Now on first glance at zpci_create_device() one may assume that there is a window where the zdev is in the list without a zdev, however this window can't overlap with __zpci_event_availability() as zpci_create_device() either runs on the same kthread as part of availability events, or during the initial CLP List PCI at which point the __zpci_event_availability() is not yet called as zPCI is not yet initialized. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Sven Schnelle authored
This fixes the following warning: CHECK linux/arch/s390/kernel/signal.c linux/arch/s390/kernel/signal.c:465:6: warning: symbol 'arch_do_signal_or_restart' was not declared. Should it be static? Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Colin Ian King authored
Rename tape_3590_erp_succeded to tape_3590_erp_succeeded to fix a spelling mistake in the function name. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Link: https://lore.kernel.org/r/20210118113222.71708-1-colin.king@canonical.com Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
- Jan 19, 2021
-
-
Sven Schnelle authored
Instead of fetching all registers from struct pt_regs and passing them to the syscall wrappers, let the system call wrappers only fetch the values really required. Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Reviewed-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Sven Schnelle authored
On s390 asmlinkage is a nop, so remove it. Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Reviewed-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Sven Schnelle authored
This patch converts s390 to use the generic entry infrastructure from kernel/entry/*. There are a few special things on s390: - PIF_PER_TRAP is moved to TIF_PER_TRAP as the generic code doesn't know about our PIF flags in exit_to_user_mode_loop(). - The old code had several ways to restart syscalls: a) PIF_SYSCALL_RESTART, which was only set during execve to force a restart after upgrading a process (usually qemu-kvm) to pgste page table extensions. b) PIF_SYSCALL, which is set by do_signal() to indicate that the current syscall should be restarted. This is changed so that do_signal() now also uses PIF_SYSCALL_RESTART. Continuing to use PIF_SYSCALL doesn't work with the generic code, and changing it to PIF_SYSCALL_RESTART makes PIF_SYSCALL and PIF_SYSCALL_RESTART more unique. - On s390 calling sys_sigreturn or sys_rt_sigreturn is implemented by executing a svc instruction on the process stack which causes a fault. While handling that fault the fault code sets PIF_SYSCALL to hand over processing to the syscall code on exit to usermode. The patch introduces PIF_SYSCALL_RET_SET, which is set if ptrace sets a return value for a syscall. The s390x ptrace ABI uses r2 both for the syscall number and return value, so ptrace cannot set the syscall number + return value at the same time. The flag makes handling that a bit easier. do_syscall() will just skip executing the syscall if PIF_SYSCALL_RET_SET is set. CONFIG_DEBUG_ASCE was removd in favour of the generic CONFIG_DEBUG_ENTRY. CR1/7/13 will be checked both on kernel entry and exit to contain the correct asces. Signed-off-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
clang does not know about the 'b1' construct used in bitops inline assembly. Since the plan is to use compiler atomic builtins anyway there is no point in requesting clang support for this. Especially if one considers that the kernel seems to be the only user of this. With removing this small optimization it is possible to compile the kernel also with -march=zEC12 and higher using clang. Build error: In file included from ./include/linux/bitops.h:32: ./arch/s390/include/asm/bitops.h:69:4: error: invalid operand in inline asm: 'oi $0,${1:b}' "oi %0,%b1\n" ^ Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Heiko Carstens authored
With commit f0cbd3b8 ("s390/atomic: circumvent gcc 10 build regression") there was an attempt to workaroud a gcc build bug, however with the workaround a similar problem with clang appeared. It was recommended to use a workaround which would fail again with gcc. Therefore simply remove the optimization. It is just not worth the effort. Besides that all of this will be changed to use compiler atomic builtins instead anyway. See https://reviews.llvm.org/D90231 and https://reviews.llvm.org/D91786 Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
Bypassing the DMA API is bad style, even when we don't expect any actual problems. Let's utilize the right API helpers for setting the DMA masks and check for returned errors, so that we benefit from common sanity checks. io_subchannel_allocate_dev() required some extra massaging, so that we can return an errno other than -ENOMEM. Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Julian Wiedmann authored
Set the bus type when initializing the cdev structure. The device core won't act on it until we call device_add(). Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by:
Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Alexander Gordeev authored
On s390 cleared_pXs flags in struct mmu_gather are set by corresponding pXd_free_tlb functions. Such approach is inconsistent with how the generic code interprets these flags, e.g pte_free_tlb() frees a PTE table - or a PMD level entity, and so on. This update does not bring any functional change, since s390 does not use the flags at the moment. Fixes: 9de7d833 ("s390/tlb: Convert to generic mmu_gather") Link: https://lore.kernel.org/lkml/fbb00ac0-9104-8d25-f225-7b3d1b17a01f@huawei.com/ Reported-by:
Zhenyu Ye <yezhenyu2@huawei.com> Suggested-by:
Gerald Schaefer <gerald.schaefer@linux.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-