- 15 Jun, 2021 10 commits
-
-
Christophe Leroy authored
Commit 328e7e48 ("powerpc: force inlining of csum_partial() to avoid multiple csum_partial() with GCC10") inlined csum_partial(). Now that csum_partial() is inlined, GCC outlines csum_add() when called by csum_partial(). c064fb28 <csum_add>: c064fb28: 7c 63 20 14 addc r3,r3,r4 c064fb2c: 7c 63 01 94 addze r3,r3 c064fb30: 4e 80 00 20 blr c0665fb8 <csum_add>: c0665fb8: 7c 63 20 14 addc r3,r3,r4 c0665fbc: 7c 63 01 94 addze r3,r3 c0665fc0: 4e 80 00 20 blr c066719c: 7c 9a c0 2e lwzx r4,r26,r24 c06671a0: 38 60 00 00 li r3,0 c06671a4: 7f 1a c2 14 add r24,r26,r24 c06671a8: 4b ff ee 11 bl c0665fb8 <csum_add> c06671ac: 80 98 00 04 lwz r4,4(r24) c06671b0: 4b ff ee 09 bl c0665fb8 <csum_add> c06671b4: 80 98 00 08 lwz r4,8(r24) c06671b8: 4b ff ee 01 bl c0665fb8 <csum_add> c06671bc: a0 98 00 0c lhz r4,12(r24) c06671c0: 4b ff ed f9 bl c0665fb8 <csum_add> c06671c4: 7c 63 18 f8 not r3,r3 c06671c8: 81 3f 00 68 lwz r9,104(r31) c06671cc: 81 5f 00 a0 lwz r10,160(r31) c06671d0: 7d 29 18 14 addc r9,r9,r3 c06671d4: 7d 29 01 94 addze r9,r9 c06671d8: 91 3f 00 68 stw r9,104(r31) c06671dc: 7d 1a 50 50 subf r8,r26,r10 c06671e0: 83 01 00 10 lwz r24,16(r1) c06671e4: 83 41 00 18 lwz r26,24(r1) The sum with 0 is useless, should have been skipped. And there is even one completely unused instance of csum_add(). In file included from ./include/net/checksum.h:22, from ./include/linux/skbuff.h:28, from ./include/linux/icmp.h:16, from net/ipv6/ip6_tunnel.c:23: ./arch/powerpc/include/asm/checksum.h: In function '__ip6_tnl_rcv': ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:172:31: note: called from here 172 | sum = csum_add(sum, (__force __wsum)*(const u32 *)buff); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:177:31: note: called from here 177 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 178 | *(const u32 *)(buff + 4)); | ~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:183:31: note: called from here 183 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 184 | *(const u32 *)(buff + 8)); | ~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:186:31: note: called from here 186 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 187 | *(const u16 *)(buff + 12)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ Force inlining of csum_add(). 94c: 80 df 00 a0 lwz r6,160(r31) 950: 7d 28 50 2e lwzx r9,r8,r10 954: 7d 48 52 14 add r10,r8,r10 958: 80 aa 00 04 lwz r5,4(r10) 95c: 80 ff 00 68 lwz r7,104(r31) 960: 7d 29 28 14 addc r9,r9,r5 964: 7d 29 01 94 addze r9,r9 968: 7d 08 30 50 subf r8,r8,r6 96c: 80 aa 00 08 lwz r5,8(r10) 970: a1 4a 00 0c lhz r10,12(r10) 974: 7d 29 28 14 addc r9,r9,r5 978: 7d 29 01 94 addze r9,r9 97c: 7d 29 50 14 addc r9,r9,r10 980: 7d 29 01 94 addze r9,r9 984: 7d 29 48 f8 not r9,r9 988: 7c e7 48 14 addc r7,r7,r9 98c: 7c e7 01 94 addze r7,r7 990: 90 ff 00 68 stw r7,104(r31) In the non-inlined version, the first sum with 0 was performed. Here it is skipped. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/f7f4d4e364de6e473da874468b903da6e5d97adc.1620713272.git.christophe.leroy@csgroup.eu
-
Michael Ellerman authored
Merge our fixes branch which has a number of important fixes, notably the fix for initrd corruption, as well as the fixes for scv vs ptrace.
-
Finn Thain authored
This avoids an (optional) compiler warning: arch/powerpc/kernel/tau_6xx.c: In function 'TAU_init': arch/powerpc/kernel/tau_6xx.c:204:30: error: too many arguments for format [-Werror=format-extra-args] tau_workq = alloc_workqueue("tau", WQ_UNBOUND, 1, 0); Fixes: b1c6a0a1 ("powerpc/tau: Convert from timer to workqueue") Reported-by:Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Finn Thain <fthain@linux-m68k.org> Signed-off-by:
-
Michael Ellerman authored
Commit b0b3b2c7 ("powerpc: Switch to relative jump labels") switched us to using relative jump labels. That involves changing the code, target and key members in struct jump_entry to be relative to the address of the jump_entry, rather than absolute addresses. We have two static inlines that create a struct jump_entry, arch_static_branch() and arch_static_branch_jump(), as well as an asm macro ARCH_STATIC_BRANCH, which is used by the pseries-only hypervisor tracing code. Unfortunately we missed updating the key to be a relative reference in ARCH_STATIC_BRANCH. That causes a pseries kernel to have a handful of jump_entry structs with bad key values. Instead of being a relative reference they instead hold the full address of the key. However the code doesn't expect that, it still adds the key value to the address of the jump_entry (see jump_entry_key()) expecting to get a pointer to a key somewhere in kernel data. The table of jump_entry structs sits in rodata, which comes after the kernel text. In a typical build this will be somewhere around 15MB. The address of the key will be somewhere in data, typically around 20MB. Adding the two values together gets us a pointer somewhere around 45MB. We then call static_key_set_entries() with that bad pointer and modify some members of the struct static_key we think we are pointing at. A pseries kernel is typically ~30MB in size, so writing to ~45MB won't corrupt the kernel itself. However if we're booting with an initrd, depending on the size and exact location of the initrd, we can corrupt the initrd. Depending on how exactly we corrupt the initrd it can either cause the system to not boot, or just corrupt one of the files in the initrd. The fix is simply to make the key value relative to the jump_entry struct in the ARCH_STATIC_BRANCH macro. Fixes: b0b3b2c7 ("powerpc: Switch to relative jump labels") Reported-by:
Anastasia Kovaleva <a.kovaleva@yadro.com> Reported-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reported-by:
Greg Kurz <groug@kaod.org> Reported-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Christophe Leroy authored
arch/powerpc/Kbuild decend into arch/powerpc/perf/ only when CONFIG_PERF_EVENTS is selected, so there is not need to take CONFIG_PERF_EVENTS into account in arch/powerpc/perf/Makefile. Signed-off-by:
Michal Suchánek <msuchanek@suse.de> Signed-off-by:
-
Andy Shevchenko authored
If by some reason any of the headers will include ctype.h we will have a name collision. Avoid this by moving isspace() to the dedicate namespace. First appearance of the code is in the commit cf68787b ("powerpc/prom_init: Evaluate mem kernel parameter for early allocation"). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> [mpe: Reformat prom_isxdigit() now that we allow longer lines] Signed-off-by:
-
Shaokun Zhang authored
Function 'event_ebb_init' and 'event_leader_ebb_init' are declared twice in the header file, so remove the repeated declaration. Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by:
-
Baokun Li authored
Fixes gcc '-Wunused-but-set-variable' warning: # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format arch/powerpc/platforms/cell/spider-pci.c: In function 'spiderpci_io_flush': arch/powerpc/platforms/cell/spider-pci.c:28:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable] It never used since introduction. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
-
Baokun Li authored
Fixes gcc '-Wunused-but-set-variable' warning: # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppu_mb_stat': arch/powerpc/platforms/cell/spufs/switch.c:1660:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppuint_mb_stat': arch/powerpc/platforms/cell/spufs/switch.c:1675:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] It never used since introduction. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Tom Rix authored
With gcc 10.3, there is this compiler error: compiler.h:56:26: error: this statement may fall through mpc52xx_gpt.c:586:2: note: here 586 | case WDIOC_GETTIMEOUT: | ^~~~ So add the fallthrough pseudo keyword. Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
- 14 Jun, 2021 1 commit
-
-
Michael Ellerman authored
In commit 96d7a4e0 ("powerpc/signal64: Rewrite handle_rt_signal64() to minimise uaccess switches") the 64-bit signal code was rearranged to use user_write_access_begin/end(). As part of that change the call to copy_siginfo_to_user() was moved later in the function, so that it could be done after the user_write_access_end(). In particular it was moved after we modify regs->nip to point to the signal trampoline. That means if copy_siginfo_to_user() fails we exit handle_rt_signal64() with an error but with regs->nip modified, whereas previously we would not modify regs->nip until the copy succeeded. Returning an error from signal delivery but with regs->nip updated leaves the process in a sort of half-delivered state. We do immediately force a SEGV in signal_setup_done(), called from do_signal(), so the process should never run in the half-delivered state. However that SEGV is not delivered until we've gone around to do_notify_resume() again, so it's possible some tracing could observe the half-delivered state. There are other cases where we fail signal delivery with regs partly updated, eg. the write to newsp and SA_SIGINFO, but the latter at least is very unlikely to fail as it reads back from the frame we just wrote to. Looking at other arches they seem to be more careful about leaving regs unchanged until the copy operations have succeeded, and in general that seems like good hygenie. So although the current behaviour is not cleary buggy, it's also not clearly correct. So move the call to copy_siginfo_to_user() up prior to the modification of regs->nip, which is closer to the old behaviour, and easier to reason about. Fixes: 96d7a4e0 ("powerpc/signal64: Rewrite handle_rt_signal64() to minimise uaccess switches") Signed-off-by:
-
- 10 Jun, 2021 6 commits
-
-
Geoff Levand authored
Commit f959dcd6 (dma-direct: Fix potential NULL pointer dereference) added a null check on the dma_mask pointer of the kernel's device structure. Add a dma_mask variable to the ps3_dma_region structure and set the device structure's dma_mask pointer to point to this new variable. Fixes runtime errors like these: # WARNING: Fixes tag on line 10 doesn't match correct format # WARNING: Fixes tag on line 10 doesn't match correct format ps3_system_bus_match:349: dev=8.0(sb_01), drv=8.0(ps3flash): match WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:151 .dma_map_page_attrs+0x34/0x1e0 ps3flash sb_01: ps3stor_setup:193: map DMA region failed Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Geoff Levand authored
To aid debugging PS3 boot problems change the log level of several PS3 device errors from pr_debug to pr_warn. Signed-off-by:
-
Geoff Levand authored
To aid debugging, add a new PS3 kernel config option PS3_VERBOSE_RESULT that, when enabled, will print more verbose messages for the result of LV1 hypercalls. Signed-off-by:
-
Geoff Levand authored
Change the PS3 linker script to align the DTB at 8 bytes, the same alignment as that of the of the 'generic' powerpc linker script. Signed-off-by:
-
Geoff Levand authored
Add a new sysfs entry /sys/firmware/ps3/fw-version that exports the PS3's firmware version. The firmware version is available through an LV1 hypercall, and we've been printing it to the boot log, but haven't provided an easy way for user utilities to get it. Signed-off-by:
-
Nathan Chancellor authored
A change in clang 13 results in the __lwsync macro being defined as __builtin_ppc_lwsync, which emits 'lwsync' or 'msync' depending on what the target supports. This breaks the build because of -Werror in arch/powerpc, along with thousands of warnings: In file included from arch/powerpc/kernel/pmc.c:12: In file included from include/linux/bug.h:5: In file included from arch/powerpc/include/asm/bug.h:109: In file included from include/asm-generic/bug.h:20: In file included from include/linux/kernel.h:12: In file included from include/linux/bitops.h:32: In file included from arch/powerpc/include/asm/bitops.h:62: arch/powerpc/include/asm/barrier.h:49:9: error: '__lwsync' macro redefined [-Werror,-Wmacro-redefined] #define __lwsync() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory") ^ <built-in>:308:9: note: previous definition is here #define __lwsync __builtin_ppc_lwsync ^ 1 error generated. Undefine this macro so that the runtime patching introduced by commit 2d1b2027 ("powerpc: Fixup lwsync at runtime") continues to work properly with clang and the build no longer breaks. Cc: stable@vger.kernel.org Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
- 06 Jun, 2021 1 commit
-
-
Christophe Leroy authored
Commit b26e8f27 ("powerpc/mem: Move cache flushing functions into mm/cacheflush.c") removed asm/sparsemem.h which is required when CONFIG_MEMORY_HOTPLUG is selected to get the declaration of create_section_mapping(). Add it back. Fixes: b26e8f27 ("powerpc/mem: Move cache flushing functions into mm/cacheflush.c") Reported-by:
-
- 01 Jun, 2021 1 commit
-
-
Frederic Barrat authored
This reverts commit 3c0468d4. That commit was breaking alignment guarantees for the DMA address when allocating coherent mappings, as described in Documentation/core-api/dma-api-howto.rst It was also noticed by Mellanox' driver: [ 1515.763621] mlx5_core c002:01:00.0: mlx5_frag_buf_alloc_node:146:(pid 13402): unexpected map alignment: 0x0800000000c61000, page_shift=16 [ 1515.763635] mlx5_core c002:01:00.0: mlx5_cqwq_create:181:(pid 13402): mlx5_frag_buf_alloc_node() failed, -12 Fixes: 3c0468d4 ("powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs") Signed-off-by:
Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
-
- 28 May, 2021 3 commits
-
-
Nicholas Piggin authored
Similar to commit 25edcc50 ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path"), ensure the P7/8 path saves and restores the host FSCR. The logic explained in that patch actually applies there to the old path well: a context switch can be made before kvmppc_vcpu_run_hv restores the host FSCR and returns. Now both the p9 and the p7/8 paths now save and restore their FSCR, it no longer needs to be restored at the end of kvmppc_vcpu_run_hv Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs") Cc: stable@vger.kernel.org # v3.14+ Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
real_vmalloc_addr() does not currently work for huge vmalloc, which is what the reverse map can be allocated with for radix host, hash guest. Extract the hugepage aware equivalent from eeh code into a helper, and convert existing sites including this one to use it. Fixes: 8abddd96 ("powerpc/64s/radix: Enable huge vmalloc mappings") Signed-off-by:
-
Naveen N. Rao authored
When checking if the probed instruction is the suffix of a prefixed instruction, we access the instruction at the previous word. If the probed instruction is the very first word of a module, we can end up trying to access an invalid page. Fix this by skipping the check for all instructions at the beginning of a page. Prefixed instructions cannot cross a 64-byte boundary and as such, we don't expect to encounter a suffix as the very first word in a page for kernel text. Even if there are prefixed instructions crossing a page boundary (from a module, for instance), the instruction will be illegal, so preventing probing on the suffix of such prefix instructions isn't worthwhile. Fixes: b4657f76 ("powerpc/kprobes: Don't allow breakpoints on suffixes") Cc: stable@vger.kernel.org # v5.8+ Reported-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
- 23 May, 2021 16 commits
-
-
Nathan Lynch authored
hvterm_raw_put_chars() calls hvc_put_chars(), which may return -EAGAIN when the underlying hcall returns a "busy" status, but udbg_hvc_putc() doesn't handle this. When using xmon on a PowerVM guest, this can result in incomplete or garbled output when printing relatively large amounts of data quickly, such as when dumping the kernel log buffer. Call again on -EAGAIN. Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by:
-
Nathan Lynch authored
Log buffer entries that are too long for dump_log_buf()'s small local buffer are: * silently discarded when a single-line entry is too long; kmsg_dump_get_line() returns true but sets &len to 0. * silently truncated to the last fitting new line when a multi-line entry is too long, e.g. register dumps from __show_regs(); this seems undetectable via the kmsg_dump API. xmon_printf()'s internal buffer is already 1KB; enlarge dump_log_buf()'s own buffer to match and make it statically allocated. Verified that this allows complete printing of register dumps on ppc64le with both CONFIG_PRINTK_TIME=y and CONFIG_PRINTK_CALLER=y. Signed-off-by:
-
Christophe Leroy authored
Commit 51c9c084 ("powerpc/kprobes: Implement Optprobes") implemented a powerpc specific version of optinsn in order to workaround the 32Mb limitation for direct branches. Instead of implementing a dedicated powerpc version, use the common optinsn and override the allocation and freeing functions. This also indirectly remove the CLANG warning about is_kprobe_ppc_optinsn_slot() not being use, and the powerpc will now benefit from commit 5b485629 ("kprobes, extable: Identify kprobes trampolines as kernel text area") Suggested-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
-
Christophe Leroy authored
Some architectures like powerpc require a non standard allocation of optinsn page, because module pages are too far from the kernel for direct branches. Define weak alloc_optinsn_page() and free_optinsn_page(), that fall back on alloc_insn_page() and free_insn_page() when not overridden by the architecture. Suggested-by:
-
Nick Desaulniers authored
Until clang-12, clang would attempt to assemble 32b powerpc assembler in 64b emulation mode when using a 64b target triple with -m32, leading to errors during the build of the compat VDSO. Simply disable all of CONFIG_COMPAT; users should upgrade to the latest release of clang for proper support. Suggested-by:
-
Nick Desaulniers authored
While looking at -Wundef warnings, the #if CONFIG_EEH stood out as a possible candidate to convert to #ifdef CONFIG_EEH. It seems that based on Kconfig dependencies it's not possible to build this file without CONFIG_EEH enabled, but based on upstream discussion, it's not clear yet that CONFIG_EEH should be enabled by default. For now, simply fix the -Wundef warning. Suggested-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Sathvika Vasireddy authored
This adds selftests for setb instruction. Signed-off-by:
Sathvika Vasireddy <sathvika@linux.vnet.ibm.com> Tested-by:
-
Sathvika Vasireddy authored
This adds emulation support for the following instruction: * Set Boolean (setb) Signed-off-by:
-
Michael Ellerman authored
Make it easier to generate a 32 or 64-bit specific randconfig. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
-
Daniel Henrique Barboza authored
We don't need the 'lmbs_available' variable to count the valid LMBs and to check if we have less than 'lmbs_to_remove'. We must ensure that the entire LMB range must be removed, so we can error out immediately if any LMB in the range is marked as reserved. Add a couple of comments explaining the reasoning behind the differences we have in this function in contrast to what it is done in its sister function, dlpar_memory_remove_by_count(). Signed-off-by:
Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Daniel Henrique Barboza authored
After marking the LMBs as reserved depending on dlpar_remove_lmb() rc, we evaluate whether we need to add the LMBs back or if we can release the LMB DRCs. In both cases, a for_each_drmem_lmb() loop without a break condition is used. This means that we're going to cycle through all LMBs of the partition even after we're done with what we were going to do. This patch adds break conditions in both loops to avoid this. The 'lmbs_removed' variable was renamed to 'lmbs_reserved', and it's now being decremented each time a lmb reservation is removed, indicating that the operation we're doing (adding back LMBs or releasing DRCs) is completed. Signed-off-by:
-
Daniel Henrique Barboza authored
DRCONF_MEM_RESERVED is a flag that represents the "Reserved Memory" status in LOPAR v2.10, section 4.2.8. If a LMB is marked as reserved, quoting LOPAR, "is not to be used or altered by the base OS". This flag is read only in the kernel, being set by the firmware/hypervisor in the DT. As an example, QEMU will set this flag in hw/ppc/spapr.c, spapr_dt_dynamic_memory(). lmb_is_removable() does not check for DRCONF_MEM_RESERVED. This function is used in dlpar_remove_lmb() as a guard before the removal logic. Since it is failing to check for !RESERVED, dlpar_remove_lmb() will fail in a later stage instead of failing in the validation when receiving a reserved LMB as input. lmb_is_removable() is also used in dlpar_memory_remove_by_count() to evaluate if we have enough LMBs to complete the request. The missing !RESERVED check in this case is causing dlpar_memory_remove_by_count() to miscalculate the number of elegible LMBs for the removal, and can make it error out later on instead of failing in the validation with the 'not enough LMBs to satisfy request' message. Making a DRCONF_MEM_RESERVED check in lmb_is_removable() fixes all these issues. Signed-off-by:
-
Daniel Henrique Barboza authored
As previously done in dlpar_cpu_remove() for CPUs, this patch changes dlpar_memory_remove_by_ic() to unisolate the LMB DRC when the LMB is failed to be removed. The hypervisor, seeing a LMB DRC that was supposed to be removed being unisolated instead, can do error recovery on its side. This change is done in dlpar_memory_remove_by_ic() only because, as of today, only QEMU is using this code path for error recovery (via the PSERIES_HP_ELOG_ID_DRC_IC event). phyp treats it as a no-op. Signed-off-by:
-
Zhen Lei authored
The statement of the last "if (xxx)" branch is the same as the "else" branch. Delete it to simplify code. No functional change. Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
Jiapeng Chong authored
Clean up the following includecheck warning: ./tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c: pthread.h is included more than once. No functional change. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
YueHaibing authored
dlpar_memory_remove() is never used, so can be removed. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
-
- 20 May, 2021 2 commits
-
-
Nicholas Piggin authored
The scv implementation missed updating syscall return value and error value get/set functions to deal with the changed register ABI. This broke ptrace PTRACE_GET_SYSCALL_INFO as well as some kernel auditing and tracing functions. Fix. tools/testing/selftests/ptrace/get_syscall_info now passes when scv is used. Fixes: 7fa95f9a ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Reported-by:
"Dmitry V. Levin" <ldv@altlinux.org> Signed-off-by:
-
Nicholas Piggin authored
powerpc/64s/syscall: Use pt_regs.trap to distinguish syscall ABI difference between sc and scv syscalls The sc and scv 0 system calls have different ABI conventions, and ptracers need to know which system call type is being used if they want to look at the syscall registers. Document that pt_regs.trap can be used for this, and fix one in-tree user to work with scv 0 syscalls. Fixes: 7fa95f9a ("powerpc/64s: system call support for scv/rfscv instructions") Cc: stable@vger.kernel.org # v5.9+ Reported-by:
-
