summaryrefslogtreecommitdiff
path: root/arch/s390
AgeCommit message (Collapse)Author
2019-09-16s390/pci: fix MSI message dataSebastian Ott
After recent changes the MSI message data needs to specify the function-relative IRQ number. Reported-and-tested-by: Alexander Schmidt <alexs@linux.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Minor overlapping changes in the btusb and ixgbe drivers. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-14Merge tag 'kvm-s390-master-5.3-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master KVM: s390: Fixes for 5.3 - prevent a user triggerable oops in the migration code - do not leak kernel stack content
2019-09-13s390: add support for IBM z15 machinesMartin Schwidefsky
Add detection for machine types 0x8562 and 8x8561 and set the ELF platform name to z15. Add the miscellaneous-instruction-extension 3 facility to the list of facilities for z15. And allow to generate code that only runs on a z15 machine. Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-09-13s390/crypto: Support for SHA3 via CPACF (MSA6)Joerg Schmidbauer
This patch introduces sha3 support for s390. - Rework the s390-specific SHA1 and SHA2 related code to provide the basis for SHA3. - Provide two new kernel modules sha3_256_s390 and sha3_512_s390 together with new kernel options. Signed-off-by: Joerg Schmidbauer <jschmidb@de.ibm.com> Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-09-13s390/startup: add pgm check info printingVasily Gorbik
Try to print out startup pgm check info including exact linux kernel version, pgm interruption code and ilc, psw and general registers. Like the following: Linux version 5.3.0-rc7-07282-ge7b4d41d61bd-dirty (gor@tuxmaker) #3 SMP PREEMPT Thu Sep 5 16:07:34 CEST 2019 Kernel fault: interruption code 0005 ilc:2 PSW : 0000000180000000 0000000000012e52 R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 RI:0 EA:3 GPRS: 0000000000000000 00ffffffffffffff 0000000000000000 0000000000019a58 000000000000bf68 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000001a041 0000000000000000 0000000004c9c000 0000000000010070 0000000000012e42 000000000000beb0 This info makes it apparent that kernel startup failed and might help to understand what went wrong without actual standalone dump. Printing code runs on its own stack of 1 page (at unused 0x5000), which should be sufficient for sclp_early_printk usage (typical stack usage observed has been around 512 bytes). The code has pgm check recursion prevention, despite pgm check info printing failure (follow on pgm check) or success it restores original faulty psw and gprs and does disabled wait. Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-09-12KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctlThomas Huth
When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject an interrupt, we convert them from the legacy struct kvm_s390_interrupt to the new struct kvm_s390_irq via the s390int_to_s390irq() function. However, this function does not take care of all types of interrupts that we can inject into the guest later (see do_inject_vcpu()). Since we do not clear out the s390irq values before calling s390int_to_s390irq(), there is a chance that we copy random data from the kernel stack which could be leaked to the userspace later. Specifically, the problem exists with the KVM_S390_INT_PFAULT_INIT interrupt: s390int_to_s390irq() does not handle it, and the function __inject_pfault_init() later copies irq->u.ext which contains the random kernel stack data. This data can then be leaked either to the guest memory in __deliver_pfault_init(), or the userspace might retrieve it directly with the KVM_S390_GET_IRQ_STATE ioctl. Fix it by handling that interrupt type in s390int_to_s390irq(), too, and by making sure that the s390irq struct is properly pre-initialized. And while we're at it, make sure that s390int_to_s390irq() now directly returns -EINVAL for unknown interrupt types, so that we immediately get a proper error code in case we add more interrupt types to do_inject_vcpu() without updating s390int_to_s390irq() sometime in the future. Cc: stable@vger.kernel.org Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/kvm/20190912115438.25761-1-thuth@redhat.com Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2019-09-12KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it ↵Igor Mammedov
as target for memset() If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling kvm_s390_vm_start_migration(), kernel will oops with: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0000000000000000 TEID: 0000000000000483 Fault in home space mode while using kernel ASCE. AS:0000000002a2000b R2:00000001bff8c00b R3:00000001bff88007 S:00000001bff91000 P:000000000000003d Oops: 0004 ilc:2 [#1] SMP ... Call Trace: ([<001fffff804ec552>] kvm_s390_vm_set_attr+0x347a/0x3828 [kvm]) [<001fffff804ecfc0>] kvm_arch_vm_ioctl+0x6c0/0x1998 [kvm] [<001fffff804b67e4>] kvm_vm_ioctl+0x51c/0x11a8 [kvm] [<00000000008ba572>] do_vfs_ioctl+0x1d2/0xe58 [<00000000008bb284>] ksys_ioctl+0x8c/0xb8 [<00000000008bb2e2>] sys_ioctl+0x32/0x40 [<000000000175552c>] system_call+0x2b8/0x2d8 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000000000dbaf60>] __memset+0xc/0xa0 due to ms->dirty_bitmap being NULL, which might crash the host. Make sure that ms->dirty_bitmap is set before using it or return -EINVAL otherwise. Cc: <stable@vger.kernel.org> Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Link: https://lore.kernel.org/kvm/20190911075218.29153-1-imammedo@redhat.com/ Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2019-09-11Merge tag 'kvm-s390-next-5.4-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD * More selftests * Improved KVM_S390_MEM_OP ioctl input checking * Add kvm_valid_regs and kvm_dirty_regs invalid bit checking
2019-09-10kexec: Fix file verification on S390Matthew Garrett
I accidentally typoed this #ifdef, so verification would always be disabled. Signed-off-by: Matthew Garrett <mjg59@google.com> Reported-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
2019-09-07pagewalk: separate function pointers from iterator dataChristoph Hellwig
The mm_walk structure currently mixed data and code. Split out the operations vectors into a new mm_walk_ops structure, and while we are changing the API also declare the mm_walk structure inside the walk_page_range and walk_page_vma functions. Based on patch from Linus Torvalds. Link: https://lore.kernel.org/r/20190828141955.22210-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-07mm: split out a new pagewalk.h header from mm.hChristoph Hellwig
Add a new header for the two handful of users of the walk_page_range / walk_page_vma interface instead of polluting all users of mm.h with it. Link: https://lore.kernel.org/r/20190828141955.22210-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-09-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller
Daniel Borkmann says: ==================== The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) Add the ability to use unaligned chunks in the AF_XDP umem. By relaxing where the chunks can be placed, it allows to use an arbitrary buffer size and place whenever there is a free address in the umem. Helps more seamless DPDK AF_XDP driver integration. Support for i40e, ixgbe and mlx5e, from Kevin and Maxim. 2) Addition of a wakeup flag for AF_XDP tx and fill rings so the application can wake up the kernel for rx/tx processing which avoids busy-spinning of the latter, useful when app and driver is located on the same core. Support for i40e, ixgbe and mlx5e, from Magnus and Maxim. 3) bpftool fixes for printf()-like functions so compiler can actually enforce checks, bpftool build system improvements for custom output directories, and addition of 'bpftool map freeze' command, from Quentin. 4) Support attaching/detaching XDP programs from 'bpftool net' command, from Daniel. 5) Automatic xskmap cleanup when AF_XDP socket is released, and several barrier/{read,write}_once fixes in AF_XDP code, from Björn. 6) Relicense of bpf_helpers.h/bpf_endian.h for future libbpf inclusion as well as libbpf versioning improvements, from Andrii. 7) Several new BPF kselftests for verifier precision tracking, from Alexei. 8) Several BPF kselftest fixes wrt endianess to run on s390x, from Ilya. 9) And more BPF kselftest improvements all over the place, from Stanislav. 10) Add simple BPF map op cache for nfp driver to batch dumps, from Jakub. 11) AF_XDP socket umem mapping improvements for 32bit archs, from Ivan. 12) Add BPF-to-BPF call and BTF line info support for s390x JIT, from Yauheni. 13) Small optimization in arm64 JIT to spare 1 insns for BPF_MOD, from Jerin. 14) Fix an error check in bpf_tcp_gen_syncookie() helper, from Petar. 15) Various minor fixes and cleanups, from Nathan, Masahiro, Masanari, Peter, Wei, Yue. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-09-05s390/crypto: xts-aes-s390 fix extra run-time crypto self tests findingHarald Freudenberger
With 'extra run-time crypto self tests' enabled, the selftest for s390-xts fails with alg: skcipher: xts-aes-s390 encryption unexpectedly succeeded on test vector "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace use_digest nosimd src_divs=[2.61%@+4006, 84.44%@+21, 1.55%@+13, 4.50%@+344, 4.26%@+21, 2.64%@+27]" This special case with nbytes=0 is not handled correctly and this fix now makes sure that -EINVAL is returned when there is en/decrypt called with 0 bytes to en/decrypt. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-05crypto: sha256 - Merge crypto/sha256.h into crypto/sha.hHans de Goede
The generic sha256 implementation from lib/crypto/sha256.c uses data structs defined in crypto/sha.h, so lets move the function prototypes there too. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-09-05crypto: s390 - Rename functions to avoid conflict with crypto/sha256.hHans de Goede
Rename static / file-local functions so that they do not conflict with the functions declared in crypto/sha256.h. This is a preparation patch for folding crypto/sha256.h into crypto/sha.h. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-09-04KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regsThomas Huth
If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this clearly indicates that something went wrong in the KVM userspace application. The x86 variant of KVM already contains a check for bad bits, so let's do the same on s390x now, too. Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/lkml/20190904085200.29021-2-thuth@redhat.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2019-09-04dma-mapping: explicitly wire up ->mmap and ->get_sgtableChristoph Hellwig
While the default ->mmap and ->get_sgtable implementations work for the majority of our dma_map_ops impementations they are inherently safe for others that don't use the page allocator or CMA and/or use their own way of remapping not covered by the common code. So remove the defaults if these methods are not wired up, but instead wire up the default implementations for all safe instances. Fixes: e1c7e324539a ("dma-mapping: always provide the dma_map_ops based implementation") Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-09-03bpf: s390: add JIT support for bpf line infoYauheni Kaliuta
This adds support for generating bpf line info for JITed programs like commit 6f20c71d8505 ("bpf: powerpc64: add JIT support for bpf line info") does for powerpc, but it should pass the array starting from 1. This fixes test_btf. Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-09-03hypfs: don't bother with d_delete()Al Viro
If that's not the last reference, d_delete() will do d_drop(). If it is, dput() immediately after it will unhash the sucker anyway, since ->d_delete() the method is always_delete_dentry(). IOW, there's no point trying to turn it into a negative hashed dentry - it won't stick around anyway. Just d_drop() it and be done with that. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-09-03s390/base: remove unused s390_base_mcck_handlerVasily Gorbik
s390_base_mcck_handler was used during system reset if diag308 set was not available. But after commit d485235b0054 ("s390: assume diag308 set always works") is a dead code and could be removed. Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-31bpf: s390: add JIT support for multi-function programsYauheni Kaliuta
This adds support for bpf-to-bpf function calls in the s390 JIT compiler. The JIT compiler converts the bpf call instructions to native branch instructions. After a round of the usual passes, the start addresses of the JITed images for the callee functions are known. Finally, to fixup the branch target addresses, we need to perform an extra pass. Because of the address range in which JITed images are allocated on s390, the offsets of the start addresses of these images from __bpf_call_base are as large as 64 bits. So, for a function call, the imm field of the instruction cannot be used to determine the callee's address. Use bpf_jit_get_func_addr() helper instead. The patch borrows a lot from: commit 8c11ea5ce13d ("bpf, arm64: fix getting subprog addr from aux for calls") commit e2c95a61656d ("bpf, ppc64: generalize fetching subprog into bpf_jit_get_func_addr") commit 8484ce8306f9 ("bpf: powerpc64: add JIT support for multi-function programs") (including the commit message). test_verifier (5.3-rc6 with CONFIG_BPF_JIT_ALWAYS_ON=y): without patch: Summary: 1501 PASSED, 0 SKIPPED, 47 FAILED with patch: Summary: 1540 PASSED, 0 SKIPPED, 8 FAILED Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Tested-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-08-29KVM: s390: Test for bad access register and size at the start of S390_MEM_OPThomas Huth
If the KVM_S390_MEM_OP ioctl is called with an access register >= 16, then there is certainly a bug in the calling userspace application. We check for wrong access registers, but only if the vCPU was already in the access register mode before (i.e. the SIE block has recorded it). The check is also buried somewhere deep in the calling chain (in the function ar_translation()), so this is somewhat hard to find. It's better to always report an error to the userspace in case this field is set wrong, and it's safer in the KVM code if we block wrong values here early instead of relying on a check somewhere deep down the calling chain, so let's add another check to kvm_s390_guest_mem_op() directly. We also should check that the "size" is non-zero here (thanks to Janosch Frank for the hint!). If we do not check the size, we could call vmalloc() with this 0 value, and this will cause a kernel warning. Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lkml.kernel.org/r/20190829122517.31042-1-thuth@redhat.com Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
2019-08-29s390/kasan: add kdump supportVasily Gorbik
If kasan enabled kernel is used as crash kernel it crashes itself with program check loop during kdump execution. The reason for that is that kasan shadow memory backed by pages beyond OLDMEM_SIZE. Make kasan memory allocator respect physical memory limit imposed by kdump. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29s390/setup: avoid using strncmp with hardcoded lengthVasily Gorbik
Replace strncmp usage in console mode setup code with simple strcmp. Replace strncmp which is used for prefix comparison with str_has_prefix. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29s390/sclp: avoid using strncmp with hardcoded lengthVasily Gorbik
"earlyprintk" option documentation does not clearly state which platform supports which additional values (e.g. ",keep"). Preserve old option behaviour and reuse str_has_prefix instead of strncmp for prefix testing. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29s390/module: avoid using strncmp with hardcoded lengthVasily Gorbik
Reuse str_has_prefix instead of strncmp with hardcoded length to make the intent of a comparison more obvious. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29s390/pci: avoid using strncmp with hardcoded lengthVasily Gorbik
Command line option values passed to __setup callbacks are always null-terminated and "s390_iommu=" may only accept "strict" as value. So replace strncmp with strcmp. While at it also make s390_iommu_setup return 1, which means this command line option is handled by this callback. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-27Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Minor conflict in r8169, bug fix had two versions in net and net-next, take the net-next hunks. Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-26s390/kaslr: reserve memory for kasan usageVasily Gorbik
Sometimes the kernel fails to boot with: "The Linux kernel failed to boot with the KernelAddressSanitizer: out of memory during initialisation" even with big amounts of memory when both kaslr and kasan are enabled. The problem is that kasan initialization code requires 1/8 of physical memory plus some for page tables. To keep as much code instrumented as possible kasan avoids using memblock for memory allocations. Instead kasan uses trivial memory allocator which simply chops off the memory from the end of online physical memory. For that reason when kaslr is enabled together with kasan avoid positioning kernel into upper memory region which would be utilized during kasan initialization. Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26s390/mem_detect: provide single get_mem_detect_endVasily Gorbik
get_mem_detect_end is already used in couple of places with potential to be utilized in more cases. Provide single get_mem_detect_end implementation in asm/mem_detect.h to be used by kasan and startup code. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26s390/cmma: reuse kstrtobool for option value parsingVasily Gorbik
"cmma" option setup already recognises some textual values. Yet kstrtobool is a more common way to parse boolean values, reuse it to unify option value parsing behavior and simplify code a bit. While at it, __setup value parsing callbacks are expected to return 1 when an option is recognized, and returning any other value won't trigger any error message currently, so simply return 1. Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26s390/vdso: reuse kstrtobool for option value parsingVasily Gorbik
"vdso" option setup already recognises integer and textual values. Yet kstrtobool is a more common way to parse boolean values, reuse it to unify option value parsing behavior and simplify code a bit. While at it, __setup value parsing callbacks are expected to return 1 when an option is recognized, and returning any other value won't trigger any error message currently, so simply return 1. Also don't change default vdso_enabled value of 1 when "vdso" option value is invalid. Reviewed-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26s390/startup: correct command line options parsingVasily Gorbik
Check val is not NULL before accessing it. This might happen if corresponding kernel command line options are used without specifying values. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26s390/numa: correct early_param handlingVasily Gorbik
When command line options are used without specifying values (e.g. "emu_size" instead of "emu_size="), the value is NULL. Check that before performing string operations and further processing. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-24s390/qeth: add TX NAPI support for IQD devicesJulian Wiedmann
Due to their large MTU and potentially low utilization of TX buffers, IQD devices in particular require fast TX recycling. This makes them a prime candidate for a TX NAPI path in qeth. qeth_tx_poll() uses the recently introduced qdio_inspect_queue() helper to poll the TX queue for completed buffers. To avoid hogging the CPU for too long, we yield to the stack after completing an entire queue's worth of buffers. While IQD is expected to transfer its buffers synchronously (and thus doesn't support TX interrupts), a timer covers for the odd case where a TX buffer doesn't complete synchronously. Currently this timer should only ever fire for (1) the mcast queue, (2) the occasional race, where the NAPI poll code observes an update to queue->used_buffers while the TX doorbell hasn't been issued yet. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-24s390/qdio: let drivers opt-out from Output Queue scanningJulian Wiedmann
If a driver wants to use the new Output Queue poll code, then the qdio layer must disable its internal Queue scanning. Let the driver select this mode by passing a special scan_threshold of 0. As the scan_threshold is the same for all Output Queues, also move it into the main qdio_irq struct. This allows for fast opt-out checking, a driver is expected to operate either _all_ or none of its Output Queues in polling mode. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-24s390/qdio: enable drivers to poll for Output completionsJulian Wiedmann
While commit d36deae75011 ("qdio: extend API to allow polling") enhanced the qdio layer so that drivers can poll their Input Queues, we don't have the corresponding infrastructure for Output Queues yet. Factor out a helper that scans a single QDIO Queue, so that qeth can implement TX NAPI on top of it. While doing so, remove the duplicated tracking of the next-to-scan index (q->first_to_check vs q->first_to_kick) in this code path. qdio_handle_aobs() needs to move slightly upwards in the code hierarchy, so that it's still called from the polling path. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Acked-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-23Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Daniel Borkmann says: ==================== pull-request: bpf 2019-08-24 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) Fix verifier precision tracking with BPF-to-BPF calls, from Alexei. 2) Fix a use-after-free in prog symbol exposure, from Daniel. 3) Several s390x JIT fixes plus BE related fixes in BPF kselftests, from Ilya. 4) Fix memory leak by unpinning XDP umem pages in error path, from Ivan. 5) Fix a potential use-after-free on flow dissector detach, from Jakub. 6) Fix bpftool to close prog fd after showing metadata, from Quentin. 7) BPF kselftest config and TEST_PROGS_EXTENDED fixes, from Anders. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-22crypto: s390/aes - fix typo in XTS_BLOCK_SIZE identifierArd Biesheuvel
Fix a typo XTS_BLOCKSIZE -> XTS_BLOCK_SIZE, causing the build to break. Fixes: ce68acbcb6a5 ("crypto: s390/xts-aes - invoke fallback for...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-22crypto: sha256 - Make lib/crypto/sha256.c suitable for generic useHans de Goede
Before this commit lib/crypto/sha256.c has only been used in the s390 and x86 purgatory code, make it suitable for generic use: * Export interesting symbols * Add -D__DISABLE_EXPORTS to CFLAGS_sha256.o for purgatory builds to avoid the exports for the purgatory builds * Add to lib/crypto/Makefile and crypto/Kconfig Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-22crypto: sha256 - Move lib/sha256.c to lib/cryptoHans de Goede
Generic crypto implementations belong under lib/crypto not directly in lib, likewise the header should be in include/crypto, not include/linux. Note that the code in lib/crypto/sha256.c is not yet available for generic use after this commit, it is still only used by the s390 and x86 purgatory code. Making it suitable for generic use is done in further patches in this series. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-22crypto: s390/xts-aes - invoke fallback for ciphertext stealingArd Biesheuvel
For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS implementations, even though no use cases are known that will be enabled by this. Since the s390 implementation already has a fallback skcipher standby for other purposes, let's use it for this purpose as well. If ciphertext stealing use cases ever become a bottleneck, we can always revisit this. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-22crypto: s390/des - switch to new verification routinesArd Biesheuvel
Switch to the refactored DES key verification routines. While at it, rename the DES encrypt/decrypt routines so they will not conflict with the DES library later on. Reviewed-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-22kbuild: add CONFIG_ASM_MODVERSIONSMasahiro Yamada
Add CONFIG_ASM_MODVERSIONS. This allows to remove one if-conditional nesting in scripts/Makefile.build. scripts/Makefile.build is run every time Kbuild descends into a sub-directory. So, I want to avoid $(wildcard ...) evaluation where possible although computing $(wildcard ...) is so cheap that it may not make measurable performance difference. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
2019-08-21s390/paes: Prepare paes functions for large key blobsHarald Freudenberger
The context used to store the key blob used a fixed 80 bytes buffer. And all the set_key functions did not even check the given key size. With CCA variable length AES cipher keys there come key blobs with about 136 bytes and maybe in the future there will arise the need to store even bigger key blobs. This patch reworks the paes set_key functions and the context buffers to work with small key blobs (<= 128 bytes) directly in the context buffer and larger blobs by allocating additional memory and storing the pointer in the context buffer. If there has been memory allocated for storing a key blob, it also needs to be freed on release of the tfm. So all the paes ciphers now have a init and exit function implemented for this job. 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>
2019-08-21s390/pkey: add CCA AES cipher key supportHarald Freudenberger
Introduce new ioctls and structs to be used with these new ioctls which are able to handle CCA AES secure keys and CCA AES cipher keys: PKEY_GENSECK2: Generate secure key, version 2. Generate either a CCA AES secure key or a CCA AES cipher key. PKEY_CLR2SECK2: Generate secure key from clear key value, version 2. Construct a CCA AES secure key or CCA AES cipher key from a given clear key value. PKEY_VERIFYKEY2: Verify the given secure key, version 2. Check for correct key type. If cardnr and domain are given, also check if this apqn is able to handle this type of key. If cardnr and domain are 0xFFFF, on return these values are filled with an apqn able to handle this key. The function also checks for the master key verification patterns of the key matching to the current or alternate mkvp of the apqn. CCA AES cipher keys are also checked for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure keys and CCA AES cipher keys are supported (may get extended in the future). PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into a protected key, version 2. Difference to version 1 is only that this new ioctl has additional parameters to provide a list of apqns to be used for the transformation. PKEY_APQNS4K: Generate a list of APQNs based on the key blob given. Is able to find out which type of secure key is given (CCA AES secure key or CCA AES cipher key) and tries to find all matching crypto cards based on the MKVP and maybe other criterias (like CCA AES cipher keys need a CEX6C or higher). The list of APQNs is further filtered by the key's mkvp which needs to match to either the current mkvp or the alternate mkvp (which is the old mkvp on CCA adapters) of the apqns. The flags argument may be used to limit the matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. PKEY_APQNS4KT: Generate a list of APQNs based on the key type given. Build a list of APQNs based on the given key type and maybe further restrict the list by given master key verification patterns. For different key types there may be different ways to match the master key verification patterns. For CCA keys (CCA data key and CCA cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp value of the apqn and the first 8 bytes of the alt_mkvp refer to the old mkvp. The flags argument controls if the apqns current and/or alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. These new ioctls are now prepared for another new type of secure key blob which may come in the future. They all use a pointer to the key blob and a key blob length information instead of some hardcoded byte array. They all use the new enums pkey_key_type, pkey_key_size and pkey_key_info for getting/setting key type, key size and additional info about the key. All but the PKEY_VERIFY2 ioctl now work based on a list of apqns. This list is walked through trying to perform the operation on exactly this apqn without any further checking (like card type or online state). If the apqn fails, simple the next one in the list is tried until success (return 0) or the end of the list is reached (return -1 with errno ENODEV). All apqns in the list need to be exact apqns (0xFFFF as any card or domain is not allowed). There are two new ioctls which can be used to build a list of apqns based on a key or key type and maybe restricted by match to a current or alternate master key verifcation pattern. 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>
2019-08-21s390/pkey: pkey cleanup: narrow in-kernel API, fix some variable typesHarald Freudenberger
There are a lot of pkey functions exported as in-kernel callable API functions but not used at all. This patch narrows down the pkey in-kernel API to what is currently only used and exploited. Within the kernel just use u32 without any leading __u32. Also functions declared in a header file in arch/s390/include/asm don't need a comment 'In-kernel API', this is by definition, otherwise the header file would be in arch/s390/include/uapi/asm. 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>
2019-08-21s390/startup: round down "mem" option to page boundaryVasily Gorbik
Make a usable value out of "mem" option once and for all. Kasan memory allocator just takes memory_end or online memory size as allocation base. If memory_end is not aligned paging structures allocated in kasan end up unaligned as well. So this change fixes potential kasan crash as well. Fixes: 78333d1f908a ("s390/kasan: add support for mem= kernel parameter") Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21s390/startup: adjust _sdma and _edma to page boundariesVasily Gorbik
Move .dma.text section alignment out of section description, otherwise zeros used to align the section are included in the section itself (and section is not really aligned by itself). $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001e38 000000000001b1c8 000000000001b1c8 0001c1c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001b1c8..0x000000000001d2bf ... Also add alignment before _edma linker symbol definition, so that entire .dma* region is rounded up to page boundaries. $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001000 000000000001c000 000000000001c000 0001d000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001c000..0x000000000001dfff ... $ cat /sys/kernel/debug/kernel_page_tables ---[ Identity Mapping ]--- 0x0000000000000000-0x000000000001c000 112K PTE RW NX 0x000000000001c000-0x000000000001d000 4K PTE RO X 0x000000000001d000-0x0000000000100000 908K PTE RW NX ... Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
generated by cgit (git 2.34.1) at 2025-09-19 10:25:54 +0000