- 05 Oct, 2022 1 commit
-
-
Nicholas Piggin authored
The value of the stack frame regs marker that gets saved on the stack in interrupt entry code does not match the regs marker value, which breaks stack frame marker matching. This stray instruction looks to have been introduced in a mismerge. Fixes: bf75a325 ("powerpc/64s/interrupt: move early boot ILE fixup into a macro") Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Mismerge by yours truly -_-] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20221004132952.984341-1-npiggin@gmail.com
-
- 04 Oct, 2022 2 commits
-
-
Nicholas Piggin authored
irq soft-masking means that when Linux irqs are disabled, the MSR[EE] value can change from 1 to 0 asynchronously: if a masked interrupt of the PACA_IRQ_MUST_HARD_MASK variety fires while irqs are disabled, the masked handler will return with MSR[EE]=0. This means a sequence like mtmsr(mfmsr() | MSR_FP) is racy if it can be called with local irqs disabled, unless a hard_irq_disable has been done. Reported-by:
Sachin Sant <sachinp@linux.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
This new assertion added is generally harmless and gets fixed up naturally, but it does indicate a problem with MSR manipulation somewhere. Fixes: c39fb71a ("powerpc/64s/interrupt: masked handler debug check for previous hard disable") Reported-by:
-
- 30 Sep, 2022 18 commits
-
-
Michael Ellerman authored
Add firmware version details to the hardware description, which is printed at boot and in case of an oops. Use /hypervisor if we find it, though currently it only exists if we're running under qemu. Look for "ibm,powervm-partition" which is specified in PAPR+ v2.11 and tells us we're running under PowerVM. Failing that look for "ibm,fw-net-version" which is seen on PowerVM going back to at least Power6. eg: Hardware name: ... of:IBM,FW860.42 (SV860_138) hv:phyp Signed-off-by:
-
Michael Ellerman authored
Add OPAL version details to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: ... opal:v6.2 Signed-off-by:
-
Michael Ellerman authored
Add the model of the machine we're on to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: IBM,8247-22L Signed-off-by:
-
Michael Ellerman authored
If we detect a logical PVR add that to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: ... 0xf000004 Signed-off-by:
-
Michael Ellerman authored
Add the PVR and CPU name to the hardware description, which is printed at boot and in case of an oops. eg: Hardware name: ... POWER8E (raw) 0x4b0201 Signed-off-by:
-
Michael Ellerman authored
Create a hardware description string, which we will use to record various details of the hardware platform we are running on. Print the accumulated description at boot, and use it to set the generic description which is printed in oopses. To begin with add ppc_md.name, aka the "machine description". Example output at boot with the full series applied: Linux version 6.0.0-rc2-gcc-11.1.0-00199-g893f9007a5ce-dirty (michael@alpine1-p1) (powerpc64-linux-gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #844 SMP Thu Sep 29 22:29:53 AEST 2022 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,git-5b4c5a pSeries printk: bootconsole [udbg0] enabled Signed-off-by:
-
Michael Ellerman authored
Make sure the ultravisor code at least gets some build testing by enabling it in powernv_defconfig. Signed-off-by:
-
Lukas Bulwahn authored
Clean up config files by: - removing configs that were deleted in the past - removing configs not in tree and without recently pending patches - adding new configs that are replacements for old configs in the file For some detailed information, see: https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulwahn@gmail.com/ Renamed: - CONFIG_PPC_PTDUMP -> CONFIG_GENERIC_PTDUMP e0847283 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP") Removed: - CONFIG_BLK_DEV_CRYPTOLOOP 47e96246 ("block: remove support for cryptoloop and the xor transfer") - CONFIG_CRYPTO_RMD128 b21b9a5e ("crypto: rmd128 - remove RIPE-MD 128 hash algorithm") - CONFIG_CRYPTO_RMD256 c15d4167 ("crypto: rmd256 - remove RIPE-MD 256 hash algorithm") - CONFIG_CRYPTO_RMD320 93f64202 ("crypto: rmd320 - remove RIPE-MD 320 hash algorithm") - CONFIG_CRYPTO_SALSA20 663f63ee ("crypto: salsa20 - remove Salsa20 stream cipher algorithm") - CONFIG_CRYPTO_TGR192 87cd723f ("crypto: tgr192 - remove Tiger 128/160/192 hash algorithms") - CONFIG_HARDENED_USERCOPY_PAGESPAN 1109a5d9 ("usercopy: Remove HARDENED_USERCOPY_PAGESPAN") - CONFIG_RAPIDIO_TSI568, CONFIG_RAPIDIO_TSI57X 612d4904 ("rapidio: remove not used code about RIO_VID_TUNDRA") - CONFIG_RAW_DRIVER 603e4922 ("remove the raw driver") - CONFIG_ROCKETPORT 3b00b6af ("tty: rocket, remove the driver") - CONFIG_ENABLE_MUST_CHECK 19679394 ("Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> [mpe: Add documentation of relevant commit for each symbol change] Signed-off-by:
-
Aneesh Kumar K.V authored
Powerpc architecture supports 16GB hugetlb pages with hash translation. For 4K page size, this is implemented as a hugepage directory entry at PGD level and for 64K it is implemented as a huge page pte at PUD level With 16GB hugetlb size, offset within a page is greater than 32 bits. Hence switch to use unsigned long type when using hugepd_shift. In order to keep things simpler, we make sure we always use unsigned long type when using hugepd_shift() even though all the hugetlb page size won't require that. The hugetlb_free_p*d_range changes are all related to nohash usage where we can have multiple pgd entries pointing to the same hugepd entries. Hence on book3s64 where we can have > 4GB hugetlb page size we will always find more < next even if we compute the value of more correctly. Hence there is no functional change in this patch except that it fixes the below warning. UBSAN: shift-out-of-bounds in arch/powerpc/mm/hugetlbpage.c:499:21 shift exponent 34 is too large for 32-bit type 'int' CPU: 39 PID: 1673 Comm: a.out Not tainted 6.0.0-rc2-00327-gee88a56e8517-dirty #1 Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) ubsan_epilogue+0x18/0x70 __ubsan_handle_shift_out_of_bounds+0x1bc/0x390 hugetlb_free_pgd_range+0x5d8/0x600 free_pgtables+0x114/0x290 exit_mmap+0x150/0x550 mmput+0xcc/0x210 do_exit+0x420/0xdd0 do_group_exit+0x4c/0xd0 sys_exit_group+0x24/0x30 system_call_exception+0x250/0x600 system_call_common+0xec/0x250 Signed-off-by:Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> [mpe: Drop generic change to be sent separately, change 1ULL to 1UL] Signed-off-by:
-
Aneesh Kumar K.V authored
For both CONFIG_NUMA enabled/disabled use mem_topology_setup() to update max/min_low_pfn. This also adds min_low_pfn update to CONFIG_NUMA which was initialized to zero before. (mpe: Though MEMORY_START is == 0 for PPC64=y which is all possible NUMA=y systems) Signed-off-by:
-
Aneesh Kumar K.V authored
This function does the hash page table update. Hence rename it to indicate this better to avoid confusion with flush_pmd_tlb_range() Signed-off-by:
-
Michael Ellerman authored
No toolchain we support should be generating stabs debug information anymore. Drop the sections entirely from our linker scripts. We removed all the manual stabs annotations in commit 12318163 ("powerpc/32: Remove remaining .stabs annotations"). Signed-off-by:
-
Michael Ellerman authored
The bulk of this was moved/reworded in: 57f26649 ("powerpc: Use gas sections for arranging exception vectors") And now appears around line 700 in arch/powerpc/kernel/exceptions-64s.S. Signed-off-by:
-
Michael Ellerman authored
This used to be about the 0x4300 handler, but that was moved in commit da2bc464 ("powerpc/64s: Add new exception vector macros"). Note that "STAB" here refers to "Segment Table" not the debug format. Signed-off-by:
-
Nicholas Piggin authored
arch/powerpc/kernel/systbl_chk.sh has not been referenced since commit ab66dcc7 ("powerpc: generate uapi header and system call table files"). Remove it. Signed-off-by:
-
Haren Myneni authored
Generally the hypervisor decides to allocate a window on different VAS instances. But if user space wishes to allocate on the current VAS instance where the process is executing, the kernel has to pass associativity domain IDs to allocate VAS window HCALL. To determine the associativity domain IDs for the current CPU, smp_processor_id() is passed to node associativity HCALL which may return H_P2 (-55) error during DLPAR CPU event. This is because Linux CPU numbers (smp_processor_id()) are not the same as the hypervisor's view of CPU numbers. Fix the issue by passing hard_smp_processor_id() with VPHN_FLAG_VCPU flag (PAPR 14.11.6.1 H_HOME_NODE_ASSOCIATIVITY). Fixes: b22f2d88 ("powerpc/pseries/vas: Integrate API with open/close windows") Reviewed-by:
Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by:
Haren Myneni <haren@linux.ibm.com> [mpe: Update change log to mention Linux vs HV CPU numbers] Signed-off-by:
-
Nicholas Piggin authored
PAPR specifies accumulated virtual processor wait intervals that relate to partition scheduling interval times. Implement these counters in the same way as they are repoted by dtl. Reviewed-by:
Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by:
-
Michael Ellerman authored
Merge some KVM commits we are keeping in our topic branch.
-
- 28 Sep, 2022 19 commits
-
-
Haren Myneni authored
The data storage interrupt (DSI) error will be generated when the paste operation is issued on the suspended Nest Accelerator (NX) window due to NX state changes. The hypervisor expects the partition to ignore this error during page fault handling. To differentiate DSI caused by an actual HW configuration or by the NX window, a new “ibm,pi-features” type value is defined. Byte 0, bit 3 of pi-attribute-specifier-type is now defined to indicate this DSI error. If this error is not ignored, the user space can get SIGBUS when the NX request is issued. This patch adds changes to read ibm,pi-features property and ignore DSI error during page fault handling if MMU_FTR_NX_DSI is defined. Signed-off-by:
-
Michael Ellerman authored
On little endian the stack frame marker appears reversed when dumping memory sequentially, as is typical in xmon or gdb, eg: c000000004733e40 0000000000000000 0000000000000000 |................| c000000004733e50 0000000000000000 0000000000000000 |................| c000000004733e60 0000000000000000 0000000000000000 |................| c000000004733e70 5347455200000000 0000000000000000 |SGER............| c000000004733e80 a700000000000000 708897f7ff7f0000 |........p.......| c000000004733e90 0073428fff7f0000 208997f7ff7f0000 |.sB..... .......| c000000004733ea0 0100000000000000 ffffffffffffffff |................| c000000004733eb0 0000000000000000 0000000000000000 |................| To make it easier to recognise, reverse the value on little endian, so it always appears as "REGS", eg: c000000004733e70 5245475300000000 0000000000000000 |REGS............| Acked-by:
-
Michael Ellerman authored
Now that the stack frame regs marker is only 32-bits it is not as obvious in memory dumps and easier to miss, eg: c000000004733e40 0000000000000000 0000000000000000 |................| c000000004733e50 0000000000000000 0000000000000000 |................| c000000004733e60 0000000000000000 0000000000000000 |................| c000000004733e70 7367657200000000 0000000000000000 |sger............| c000000004733e80 a700000000000000 708897f7ff7f0000 |........p.......| c000000004733e90 0073428fff7f0000 208997f7ff7f0000 |.sB..... .......| c000000004733ea0 0100000000000000 ffffffffffffffff |................| c000000004733eb0 0000000000000000 0000000000000000 |................| So make it upper case to make it stand out a bit more: c000000004733e70 5347455200000000 0000000000000000 |SGER............| Acked-by:
-
Li Huafei authored
I found a null pointer reference in arch_prepare_kprobe(): # echo 'p cmdline_proc_show' > kprobe_events # echo 'p cmdline_proc_show+16' >> kprobe_events Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000000050bfc Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e563 #10 NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e563) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 88002444 XER: 20040006 CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0 ... NIP arch_prepare_kprobe+0x10c/0x2d0 LR arch_prepare_kprobe+0xfc/0x2d0 Call Trace: 0xc0000000012f77a0 (unreliable) register_kprobe+0x3c0/0x7a0 __register_trace_kprobe+0x140/0x1a0 __trace_kprobe_create+0x794/0x1040 trace_probe_create+0xc4/0xe0 create_or_delete_trace_kprobe+0x2c/0x80 trace_parse_run_command+0xf0/0x210 probes_write+0x20/0x40 vfs_write+0xfc/0x450 ksys_write+0x84/0x140 system_call_exception+0x17c/0x3a0 system_call_vectored_common+0xe8/0x278 --- interrupt: 3000 at 0x7fffa5682de0 NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000 REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e563) MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 44002408 XER: 00000000 The address being probed has some special: cmdline_proc_show: Probe based on ftrace cmdline_proc_show+16: Probe for the next instruction at the ftrace location The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets set to NULL. In arch_prepare_kprobe() it will check for: ... prev = get_kprobe(p->addr - 1); preempt_enable_no_resched(); if (prev && ppc_inst_prefixed(ppc_inst_read(prev->ainsn.insn))) { ... If prev is based on ftrace, 'ppc_inst_read(prev->ainsn.insn)' will occur with a null pointer reference. At this point prev->addr will not be a prefixed instruction, so the check can be skipped. Check if prev is ftrace-based kprobe before reading 'prev->ainsn.insn' to fix this problem. Fixes: b4657f76 ("powerpc/kprobes: Don't allow breakpoints on suffixes") Signed-off-by:
Li Huafei <lihuafei1@huawei.com> [mpe: Trim oops] Signed-off-by:
-
ye xingchen authored
Return the value opal_npu_spa_clear_cache() directly instead of storing it in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
ye xingchen authored
Return the value vas_register_coproc_api() directly instead of storing it in another redundant variable. Reported-by:
-
Nathan Lynch authored
At boot time, it is not necessary to delay between polls of cpu_callin_map when waiting for a kicked CPU to come up. Remove the delay intervals, but preserve the overall deadline (five seconds). At run time, the first poll result is usually negative and we incur a sleeping wait. If we spin on the callin word for a short time first, we can reduce __cpu_up() from dozens of milliseconds to under 1ms in the common case on a P9 LPAR: $ ppc64_cpu --smt=off $ bpftrace -e 'kprobe:__cpu_up { @start[tid] = nsecs; } kretprobe:__cpu_up /@start[tid]/ { @us = hist((nsecs - @start[tid]) / 1000); delete(@start[tid]); }' -c 'ppc64_cpu --smt=on' Before: @us: [16K, 32K) 85 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [32K, 64K) 13 |@@@@@@@ | After: @us: [128, 256) 95 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [256, 512) 3 |@ | Signed-off-by: -
Nathan Lynch authored
The error injection facility on pseries VMs allows corruption of arbitrary guest memory, potentially enabling a sufficiently privileged user to disable lockdown or perform other modifications of the running kernel via the rtas syscall. Block the PAPR error injection facility from being opened or called when locked down. Signed-off-by:
-
Nathan Lynch authored
The /proc/powerpc/ofdt interface allows the root user to freely alter the in-kernel device tree, enabling arbitrary physical address writes via drivers that could bind to malicious device nodes, thus making it possible to disable lockdown. Historically this interface has been used on the pseries platform to facilitate the runtime addition and removal of processor, memory, and device resources (aka Dynamic Logical Partitioning or DLPAR). Years ago, the processor and memory use cases were migrated to designs that happen to be lockdown-friendly: device tree updates are communicated directly to the kernel from firmware without passing through untrusted user space. I/O device DLPAR via the "drmgr" command in powerpc-utils remains the sole legitimate user of /proc/powerpc/ofdt, but it is already broken in lockdown since it uses /dev/mem to allocate argument buffers for the rtas syscall. So only illegitimate uses of the interface should see a behavior change when running on a locked down kernel. Signed-off-by:
-
Pali Rohár authored
'extern' keyword is pointless and deprecated for function prototypes. Signed-off-by:
Pali Rohár <pali@kernel.org> Suggested-by:
Gabriel Paubert <paubert@iram.es> Signed-off-by:
-
Pali Rohár authored
uImage boot wrapper should not use SPE instructions, like kernel itself. Boot wrapper has already disabled Altivec and VSX instructions but not SPE. Options -mno-spe and -mspe=no already set when compilation of kernel, but not when compiling uImage wrapper yet. Fix it. Cc: stable@vger.kernel.org Signed-off-by:
-
Pali Rohár authored
There are still some board device tree files without Power ISA properties which have Freescale e500v1 cores, namely those which are based on Freescale mpc8540, mpc8541, mpc8555 and mpc8560 processors. So include newly introduced e500v1_power_isa.dtsi file in devices tree files with those processors. Signed-off-by:
-
Pali Rohár authored
Commit 2eb28006 ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1") introduced new include file e500v2_power_isa.dtsi and should have used it for all e500v2 platforms. But apparently it was used also for e500v1 platforms mpc8540, mpc8541, mpc8555 and mpc8560. e500v1 cores compared to e500v2 do not support double precision floating point SPE instructions. Hence power-isa-sp.fd should not be set on e500v1 platforms, which is in e500v2_power_isa.dtsi include file. Fix this issue by introducing a new e500v1_power_isa.dtsi include file and use it in all e500v1 device tree files. Fixes: 2eb28006 ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1") Signed-off-by:
-
Athira Rajeev authored
For PERF_SAMPLE_BRANCH_STACK sample type, different branch_sample_type, ie branch filters are supported. The testcase "bhrb_filter_map_test" tests the valid and invalid filter maps in different powerpc platforms. Update this testcase to include scenario to cover multiple branch filters at sametime. Since powerpc doesn't support multiple filters at sametime, expect failure during perf_event_open. Reported-by:
Disha Goel <disgoel@linux.vnet.ibm.com> Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
-
Athira Rajeev authored
For PERF_SAMPLE_BRANCH_STACK sample type, different branch_sample_type ie branch filters are supported. The branch filters are requested via event attribute "branch_sample_type". Multiple branch filters can be passed in event attribute. eg: $ perf record -b -o- -B --branch-filter any,ind_call true None of the Power PMUs support having multiple branch filters at the same time. Branch filters for branch stack sampling is set via MMCRA IFM bits [32:33]. But currently when requesting for multiple filter types, the "perf record" command does not report any error. eg: $ perf record -b -o- -B --branch-filter any,save_type true $ perf record -b -o- -B --branch-filter any,ind_call true The "bhrb_filter_map" function in PMU driver code does the validity check for supported branch filters. But this check is done for single filter. Hence "perf record" will proceed here without reporting any error. Fix power_pmu_event_init() to return EOPNOTSUPP when multiple branch filters are requested in the event attr. After the fix: $ perf record --branch-filter any,ind_call -- ls Error: cycles: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat' Reported-by:
Madhavan Srinivasan <maddy@linux.ibm.com> Reviewed-by:
-
Nicholas Piggin authored
Ensure r13 is zero from very early in boot until it gets set to the boot paca pointer. This allows early program and mce handlers to halt if there is no valid paca, rather than potentially run off into the weeds. This preserves register and memory contents for low level debugging tools. Nothing could be printed to console at this point in any case because even udbg is only set up after the boot paca is set, so this shouldn't be missed. Signed-off-by:
-
Nicholas Piggin authored
The idea is to get to the point where if r13 is non-zero, then it should contain a reasonable paca. This can be used in early boot program check and machine check handlers to avoid running off into the weeds if they hit before r13 has a paca. Signed-off-by:
-
Nicholas Piggin authored
relocate() uses r13 in early boot before it is used for the paca. Use a different register for this so r13 is kept unchanged until it is set to the paca pointer. Avoid r14 as well while we're here, there's no reason not to use the volatile registers which is a bit less surprising, and r14 could be used as another fixed reg one day. Signed-off-by:
-
Nicholas Piggin authored
Use the early boot interrupt fixup in the machine check handler to allow the machine check handler to run before interrupt endian is set up. Branch to an early boot handler that just does a basic crash, which allows it to run before ppc_md is set up. MSR[ME] is enabled on the boot CPU earlier, and the machine check stack is temporarily set to the middle of the init task stack. This allows machine checks (e.g., due to invalid data access in real mode) to print something useful earlier in boot (as soon as udbg is set up, if CONFIG_PPC_EARLY_DEBUG=y). Signed-off-by:
-
