- 19 Jun, 2023 4 commits
-
-
Benjamin Gray authored
Recognise and pass the appropriate signal to the user program when a hashchk instruction triggers. This is independent of allowing configuration of DEXCR[NPHIE], as a hypervisor can enforce this aspect regardless of the kernel. The signal mirrors how ARM reports their similar check failure. For example, their FPAC handler in arch/arm64/kernel/traps.c do_el0_fpac() does this. When we fail to read the instruction that caused the fault we send a segfault, similar to how emulate_math() does it. Signed-off-by:
Benjamin Gray <bgray@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616034846.311705-5-bgray@linux.ibm.com
-
Benjamin Gray authored
ISA 3.1B introduces the Dynamic Execution Control Register (DEXCR). It is a per-cpu register that allows control over various CPU behaviours including branch hint usage, indirect branch speculation, and hashst/hashchk support. Add some definitions and basic support for the DEXCR in the kernel. Right now it just * Initialises the DEXCR and HASHKEYR to a fixed value when a CPU onlines. * Clears them in reset_sprs(). * Detects when the NPHIE aspect is supported (the others don't get looked at in this series, so there's no need to waste a CPU_FTR on them). We initialise the HASHKEYR to ensure that all cores have the same key, so an HV enforced NPHIE + swapping cores doesn't randomly crash a process using hash instructions. The stores to HASHKEYR are unconditional because the ISA makes no mention of the SPR being missing if support for doing the hashes isn't present. So all that would happen is the HASHKEYR value gets ignored. This helps slightly if NPHIE detection fails; e.g., we currently only detect it on pseries. Signed-off-by: -
Benjamin Gray authored
ptrace-decl.h uses user_regset_get2_fn (among other things) from regset.h. While all current users of ptrace-decl.h include regset.h before it anyway, it adds an implicit ordering dependency and breaks source tooling that tries to inspect ptrace-decl.h by itself. Signed-off-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
-
Benjamin Gray authored
The functions here use struct task_struct fields, so need to import the full definition from <linux/sched.h>. The <asm/current.h> header that defines current only forward declares struct task_struct. Failing to include this <linux/sched.h> header leads to a compilation error when a translation unit does not also include <linux/sched.h> indirectly. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
-
- 15 Jun, 2023 4 commits
-
-
Nicholas Piggin authored
Add --orphan-handlin for vdsos, and adjust vdso linker scripts to deal with orphan sections. Signed-off-by:
-
Nicholas Piggin authored
The refcount on mm is dropped before the coprocessor is detached. Reported-by:
Sachin Sant <sachinp@linux.ibm.com> Fixes: 7bc6f71b ("powerpc/vas: Define and use common vas_window struct") Fixes: b22f2d88 ("powerpc/pseries/vas: Integrate API with open/close windows") Signed-off-by:
-
Nicholas Piggin authored
This file contains only the enter_prom implementation now. Trim includes and update header comment while we're here. Signed-off-by:
-
Nicholas Piggin authored
The _switch stack frame setup are substantially the same, so are the comments. The difference in how the stack and current are switched, and other hardware and software housekeeping is done is moved into macros. Generated code should be unchanged. Signed-off-by:
-
- 14 Jun, 2023 16 commits
-
-
Nicholas Piggin authored
Change the order of some operations and change some register numbers in preparation to merge 32-bit and 64-bit switch. Signed-off-by:
-
Nicholas Piggin authored
64-bit has removed the sync from _switch since commit 9145effd ("powerpc/64: Drop explicit hwsync in context switch"). The same logic there should apply to 32-bit. Remove the sync and replace with a placeholder comment (32 and 64 will be merged with a later change). Signed-off-by:
-
Nicholas Piggin authored
More some 64-bit specifics out from the function epilogue and rearrange this to be a bit neater, use 32-bit mem ops for CR save/restore, and change some register numbers. This is preparation to consolidate 32-bit and 64-bit switch code. Signed-off-by:
-
Nicholas Piggin authored
The large hunk of SLB pinning in _switch asm code makes it more difficult to see everything else that's going on. It is a less important path now, so icache and fetch footprint overhead can be avoided. Move context switch stack SLB pinning out of line. Signed-off-by:
-
Nicholas Piggin authored
LLVM assembler does not recognise 3-operand cmpi, use cmpwi. Signed-off-by:
-
Nicholas Piggin authored
ELFv2 was introduced together with little-endian. ELFv1 with LE has never been a thing. The GNU toolchain can create such a beast, but anyone doing that is a maniac who needs to be stopped so I consider this patch a feature. Signed-off-by:
-
Nicholas Piggin authored
-mprofile-kernel is an optimised calling convention for mcount that Linux has only implemented with the ELFv2 ABI, so it was disabled for big endian kernels. However it does work with ELFv2 big endian, so let's allow that if the compiler supports it. Acked-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Suggested-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Nicholas Piggin authored
All supported toolchains now support ELFv2 on big-endian, so flip the default on this and hide the option behind EXPERT for the purpose of bug hunting. Signed-off-by:
-
Nicholas Piggin authored
The LLVM linker does not support ELFv1 at all, so BE kernels must be built with ELFv2. The LLD version check was added to be conservative, LLD simply fails to link ELFv1 entirely, effectively requiring LLD >= 15 and ELFv2 for BE builds. Instead remove that restriction until proven otherwise (LLD 14.0 links a booting ELFv2 BE vmlinux for me). The minimum GNU binutils has increased such that ELFv2 is always supported, so remove that check while we're here. Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
-
Nicholas Piggin authored
x86 removed -pipe in commit 437e88ab ("x86/build: Remove -pipe from KBUILD_CFLAGS") and the newer arm64 and riscv seem to have never used it, so that seems to be the way the world's going. Compile performance building defconfig on a POWER10 PowerNV system was in the noise after 10 builds each. No point in adding options unless they help something, so remove it. Signed-off-by:
-
Nicholas Piggin authored
Tidy pass over boot Makefile. Move variables together where possible. Signed-off-by:
-
Nicholas Piggin authored
BOOTCFLAGS no longer contains anything that BOOTASFLAGS needs (except -pipe). Separate them to avoid fragility with cross-contamination of flags which has caused several build problems. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/lkml/CAHk-=whyWUdJDeOBN1hRWYSkQkvzYiQ5RbSW5rJjExgnbSNX9Q@mail.gmail.com/Signed-off-by:
-
Nicholas Piggin authored
Add BOOTCPPFLAGS variable for the CPP options required by C and AS. Signed-off-by:
-
Nicholas Piggin authored
Add BOOTTARGETFLAGS variable with target / ABI options common to CFLAGS and AFLAGS. Signed-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Reviewed-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
- 09 Jun, 2023 11 commits
-
-
Christophe Leroy authored
Looking at generated code for handle_signal32() shows calls to a function called __unsafe_save_user_regs.constprop.0 while user access is open. And that __unsafe_save_user_regs.constprop.0 function has two nops at the begining, allowing it to be traced, which is unexpected during user access open window. The solution could be to mark __unsafe_save_user_regs() no trace, but to be on the safe side the most efficient is to flag it __always_inline as already done for function __unsafe_restore_general_regs(). The function is relatively small and only called twice, so the size increase will remain in the noise. Do the same with save_tm_user_regs_unsafe() as it may suffer the same issue. Fixes: ef75e731 ("powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version") Signed-off-by:
-
Christophe Leroy authored
A disassembly of interrupt_exit_kernel_prepare() shows a useless read of MSR register. This is shown by r9 being re-used immediately without doing anything with the value read. c000e0e0: 60 00 00 00 nop c000e0e4: 7d 3a c2 a6 mfmd_ap r9 c000e0e8: 7d 20 00 a6 mfmsr r9 c000e0ec: 7c 51 13 a6 mtspr 81,r2 c000e0f0: 81 3f 00 84 lwz r9,132(r31) c000e0f4: 71 29 80 00 andi. r9,r9,32768 This is due to the use of local_irq_save(). The flags read by local_irq_save() are never used, use local_irq_disable() instead. Fixes: 13799748 ("powerpc/64: use interrupt restart table to speed up return from interrupt") Signed-off-by:
-
Christophe Leroy authored
The following boottime error is encountered with SMP kernel: kcsan: improperly instrumented type=(0): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(0): spin_unlock(&test_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE): spin_unlock(&test_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND): arch_spin_unlock(&arch_spinlock) kcsan: improperly instrumented type=(KCSAN_ACCESS_WRITE | KCSAN_ACCESS_COMPOUND): spin_unlock(&test_spinlock) kcsan: selftest: test_barrier failed kcsan: selftest: 2/3 tests passed Kernel panic - not syncing: selftests failed Properly instrument arch_spin_unlock() with kcsan_mb(). Signed-off-by:
Marco Elver <elver@google.com> Signed-off-by:
-
Christophe Leroy authored
The stubs were provided by commit 725aea87 ("xtensa: enable KCSAN") to make linker happy allthought they are not meant to be used at all. KCSAN core has been fixed to not require them anymore on 32 bits architectures. Then they can be removed. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Acked-by:
-
Rohan McLure authored
Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options. Boots and passes selftests on 32-bit and 64-bit platforms. See documentation in Documentation/dev-tools/kcsan.rst for more information. Signed-off-by:
Rohan McLure <rmclure@linux.ibm.com> Signed-off-by:
-
Christophe Leroy authored
Activating KCSAN on a 32 bits architecture leads to the following link-time failure: LD .tmp_vmlinux.kallsyms1 powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_load': kernel/kcsan/core.c:1273: undefined reference to `__atomic_load_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_store': kernel/kcsan/core.c:1273: undefined reference to `__atomic_store_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_exchange': kernel/kcsan/core.c:1273: undefined reference to `__atomic_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_add': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_add_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_sub': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_sub_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_and': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_and_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_or': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_or_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_xor': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_xor_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_fetch_nand': kernel/kcsan/core.c:1273: undefined reference to `__atomic_fetch_nand_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_strong': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_weak': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' powerpc64-linux-ld: kernel/kcsan/core.o: in function `__tsan_atomic64_compare_exchange_val': kernel/kcsan/core.c:1273: undefined reference to `__atomic_compare_exchange_8' 32 bits architectures don't have 64 bits atomic builtins. Only include DEFINE_TSAN_ATOMIC_OPS(64) on 64 bits architectures. Fixes: 0f8ad5f2 ("kcsan: Add support for atomic builtins") Suggested-by: -
Randy Dunlap authored
When CONFIG_SMP is not set, CONFIG_BROKEN_ON_SMP is set, and CONFIG_PCI is not set, there can be a kconfig warning: WARNING: unmet direct dependencies detected for PPC_INDIRECT_PCI Depends on [n]: PCI [=n] Selected by [y]: - MPC10X_BRIDGE [=y] To fix that, make the selects of MPC10X_BRIDGE be conditional on PCI and use "imply" instead of "select". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by: Michael Ellerman <mpe@ellerman.id.au> # use "imply" Signed-off-by:
-
Nicholas Piggin authored
Michael is merging KVM PPC patches via the powerpc tree and KVM topic branches. He doesn't necessarily have time to be across all of KVM so is reluctant to call himself maintainer, but for the mechanics of how patches flow upstream, it is maintained and does make sense to have some contact people in MAINTAINERS. So add Michael Ellerman as KVM PPC maintainer and myself as reviewer. Split out the subarchs that don't get so much attention. Signed-off-by:
-
Michael Ellerman authored
Ben no longer has time to do any maintenance of the powermac code. Mark it as orphan. Signed-off-by:
-
Michael Ellerman authored
The powerpc section has a "F:" entry for drivers/macintosh, matching all files in or below drivers/macintosh. That is correct for the most part, but there are a couple of m68k-only drivers in the directory, so exclude those. Acked-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Michael Ellerman authored
Merge our fixes branch, in particular to bring in the change to arch/powerpc/boot/Makefile, which is depended upon by a subsequent series.
-
- 30 May, 2023 3 commits
-
-
Maninder Singh authored
kallsyms_lookup() which in turn calls kallsyms_lookup_buildid() writes to index "KSYM_NAME_LEN - 1". Thus the array passed as namebuf to kallsyms_lookup() should be KSYM_NAME_LEN in size. In xmon.c the array was defined to be "128" bytes directly, without using KSYM_NAME_LEN. Commit b8a94bfb ("kallsyms: increase maximum kernel symbol length to 512") changed the value to 512, but missed updating the xmon code. Fixes: b8a94bfb ("kallsyms: increase maximum kernel symbol length to 512") Cc: stable@vger.kernel.org # v6.1+ Co-developed-by:
Onkarnath <onkarnath.1@samsung.com> Signed-off-by:
Maninder Singh <maninder1.s@samsung.com> [mpe: Tweak change log wording and fix commit reference] Signed-off-by:
-
Gaurav Batra authored
Currently in tce_freemulti_pSeriesLP() there is no limit on how many TCEs are passed to the H_STUFF_TCE hcall. This has not caused an issue until now, but newer firmware releases have started enforcing a limit of 512 TCEs per call. The limit is correct per the specification (PAPR v2.12 § 14.5.4.2.3). The code has been in it's current form since it was initially merged. Cc: stable@vger.kernel.org Signed-off-by:
Gaurav Batra <gbatra@linux.vnet.ibm.com> Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> [mpe: Tweak change log wording & add PAPR reference] Signed-off-by:
-
Michael Ellerman authored
The recently added P10 AES/GCM code added some files containing CRYPTOGAMS perl-asm code which are near duplicates of the p8 files found in drivers/crypto/vmx. In particular the newly added files produce functions with identical names to the existing code. When the kernel is built with CONFIG_CRYPTO_AES_GCM_P10=y and CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y that leads to link errors, eg: ld: drivers/crypto/vmx/aesp8-ppc.o: in function `aes_p8_set_encrypt_key': (.text+0xa0): multiple definition of `aes_p8_set_encrypt_key'; arch/powerpc/crypto/aesp8-ppc.o:(.text+0xa0): first defined here ... ld: drivers/crypto/vmx/ghashp8-ppc.o: in function `gcm_ghash_p8': (.text+0x140): multiple definition of `gcm_ghash_p8'; arch/powerpc/crypto/ghashp8-ppc.o:(.text+0x2e4): first defined here Fix it for now by renaming the newly added files and functions to use "p10" instead of "p8" in the names. Fixes: 45a4672b ("crypto: p10-aes-gcm - Update Kconfig and Makefile") Tested-by:
Vishal Chourasia <vishalc@linux.ibm.com> Signed-off-by:
-
- 21 May, 2023 1 commit
-
-
Michael Ellerman authored
Commit 1e8fed87 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") removed the limits on the possible values for ARCH_FORCE_MAX_ORDER. However removing the ranges entirely causes some common work flows to break. For example building a defconfig (which uses 64K pages), changing the page size to 4K, and rebuilding used to work, because ARCH_FORCE_MAX_ORDER would be clamped to 12 by the ranges. With the ranges removed it creates a kernel that builds but crashes at boot: kernel BUG at mm/huge_memory.c:470! Oops: Exception in kernel mode, sig: 5 [#1] ... NIP hugepage_init+0x9c/0x278 LR do_one_initcall+0x80/0x320 Call Trace: do_one_initcall+0x80/0x320 kernel_init_freeable+0x304/0x3ac kernel_init+0x30/0x1a0 ret_from_kernel_user_thread+0x14/0x1c The reasoning for removing the ranges was that some of the values were too large. So take that into account and limit the maximums to 10 which is the default max, except for the 4K case which uses 12. Fixes: 1e8fed87 ("powerpc: drop ranges for definition of ARCH_FORCE_MAX_ORDER") Signed-off-by:
-
- 16 May, 2023 1 commit
-
-
Gaurav Batra authored
For an SR-IOV device, while enabling DDW, a new table is created and added at index 1 in the group. In the below 2 scenarios, the table is incorrectly referenced at index 0 (which is where the table is for default DMA window). 1. When adding DDW This issue is exposed with "slub_debug". Error thrown out from dma_iommu_dma_supported() Warning: IOMMU offset too big for device mask mask: 0xffffffff, table offset: 0x800000000000000 2. During Dynamic removal of the PCI device. Error is from iommu_tce_table_put() since a NULL table pointer is passed in. Fixes: 381ceda8 ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by:
-
