Re: [PATCH 3/5] bpf ppc64: Add instructions for atomic_[cmp]xchg
On Thu, 2022-05-12 at 13:15 +0530, Hari Bathini wrote: > This adds two atomic opcodes BPF_XCHG and BPF_CMPXCHG on ppc64, both > of which include the BPF_FETCH flag. The kernel's atomic_cmpxchg > operation fundamentally has 3 operands, but we only have two register > fields. Therefore the operand we compare against (the kernel's API > calls it 'old') is hard-coded to be BPF_REG_R0. Also, kernel's > atomic_cmpxchg returns the previous value at dst_reg + off. JIT the > same for BPF too with return value put in BPF_REG_0. > > BPF_REG_R0 = atomic_cmpxchg(dst_reg + off, BPF_REG_R0, src_reg); > > Signed-off-by: Hari Bathini > --- > arch/powerpc/net/bpf_jit_comp64.c | 28 > 1 file changed, 24 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/net/bpf_jit_comp64.c > b/arch/powerpc/net/bpf_jit_comp64.c > index 504fa459f9f3..df9e20b22ccb 100644 > --- a/arch/powerpc/net/bpf_jit_comp64.c > +++ b/arch/powerpc/net/bpf_jit_comp64.c > @@ -783,6 +783,9 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 > *image, struct codegen_context * > */ > case BPF_STX | BPF_ATOMIC | BPF_W: > case BPF_STX | BPF_ATOMIC | BPF_DW: > + u32 save_reg = tmp2_reg; > + u32 ret_reg = src_reg; Hi Hari, Some compilers[0][1] don't like these late declarations after case labels: arch/powerpc/net/bpf_jit_comp64.c: In function ‘bpf_jit_build_body’: arch/powerpc/net/bpf_jit_comp64.c:781:4: error: a label can only be part of a statement and a declaration is not a statement u32 save_reg = tmp2_reg; ^~~ arch/powerpc/net/bpf_jit_comp64.c:782:4: error: expected expression before ‘u32’ u32 ret_reg = src_reg; ^~~ arch/powerpc/net/bpf_jit_comp64.c:819:5: error: ‘ret_reg’ undeclared (first use in this function); did you mean ‘dst_reg’? ret_reg = bpf_to_ppc(BPF_REG_0); Adding a semicolon fixes the first issue, i.e. case BPF_STX | BPF_ATOMIC | BPF_DW: ; but then it just complains about mixed declarations and code instead. So you should declare save_reg and ret_reg at the beginning of the for loop like the rest of the variables. - Russell [0]: gcc 5.5.0 https://github.com/ruscur/linux-ci/runs/6418546193?check_suite_focus=true#step:4:122 [1]: clang 12.0 https://github.com/ruscur/linux-ci/runs/6418545338?check_suite_focus=true#step:4:117 > + > /* Get offset into TMP_REG_1 */ > EMIT(PPC_RAW_LI(tmp1_reg, off)); > tmp_idx = ctx->idx * 4; > @@ -813,6 +816,24 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 > *image, struct codegen_context * > case BPF_XOR | BPF_FETCH: > EMIT(PPC_RAW_XOR(tmp2_reg, tmp2_reg, > src_reg)); > break; > + case BPF_CMPXCHG: > + /* > + * Return old value in BPF_REG_0 for > BPF_CMPXCHG & > + * in src_reg for other cases. > + */ > + ret_reg = bpf_to_ppc(BPF_REG_0); > + > + /* Compare with old value in BPF_R0 > */ > + if (size == BPF_DW) > + EMIT(PPC_RAW_CMPD(bpf_to_ppc( > BPF_REG_0), tmp2_reg)); > + else > + EMIT(PPC_RAW_CMPW(bpf_to_ppc( > BPF_REG_0), tmp2_reg)); > + /* Don't set if different from old > value */ > + PPC_BCC_SHORT(COND_NE, (ctx->idx + 3) > * 4); > + fallthrough; > + case BPF_XCHG: > + save_reg = src_reg; > + break; > default: > pr_err_ratelimited( > "eBPF filter atomic op code > %02x (@%d) unsupported\n", > @@ -822,15 +843,14 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 > *image, struct codegen_context * > > /* store new value */ > if (size == BPF_DW) > - EMIT(PPC_RAW_STDCX(tmp2_reg, > tmp1_reg, dst_reg)); > + EMIT(PPC_RAW_STDCX(save_reg, > tmp1_reg, dst_reg)); > else > - EMIT(PPC_RAW_STWCX(tmp2_reg, > tmp1_reg, dst_reg)); > + EMIT(PPC_RAW_STWCX(save_reg, > tmp1_reg, dst_reg)); > /* we're done if this succeeded */ > PPC_BCC_SHORT(COND_NE, tmp_idx); > > - /* For the BPF_FETCH variant, get old value > into src_reg */ > if (imm & BPF_FETCH) > - EMIT
[powerpc:next-test] BUILD SUCCESS 5a915665235fbb6e13961870b670ba8445746f52
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: 5a915665235fbb6e13961870b670ba8445746f52 powerpc/64: Only WARN if __pa()/__va() called with bad addresses elapsed time: 725m configs tested: 55 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm allmodconfig arm allyesconfig arm defconfig arm64 defconfig arm64allyesconfig ia64defconfig ia64 allmodconfig ia64 allyesconfig m68kdefconfig m68k allyesconfig m68k allmodconfig nios2 defconfig arc allyesconfig alpha defconfig cskydefconfig alphaallyesconfig nios2allyesconfig arc defconfig sh allmodconfig h8300allyesconfig xtensa allyesconfig parisc defconfig s390 allmodconfig parisc allyesconfig s390defconfig s390 allyesconfig parisc64defconfig sparc defconfig sparcallyesconfig i386 debian-10.3-kselftests i386 debian-10.3 i386defconfig i386 allyesconfig mips allyesconfig mips allmodconfig powerpc allnoconfig powerpc allmodconfig powerpc allyesconfig riscvnommu_k210_defconfig riscv defconfig riscvnommu_virt_defconfig riscv allnoconfig riscvallyesconfig riscvallmodconfig riscv rv32_defconfig um x86_64_defconfig um i386_defconfig x86_64 rhel-8.3-func x86_64 rhel-8.3-syz x86_64 kexec x86_64 defconfig x86_64 allyesconfig x86_64rhel-8.3-kselftests x86_64 rhel-8.3-kunit x86_64 rhel-8.3 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: [PATCH 24/30] panic: Refactor the panic path
On 12/05/2022 11:03, Petr Mladek wrote: > Hello, > > first, I am sorry for stepping into the discussion so late. > I was busy with some other stuff and this patchset is far > from trivial. > > Second, thanks a lot for putting so much effort into it. > Most of the changes look pretty good, especially all > the fixes of particular notifiers and split into > four lists. > > Though this patch will need some more love. See below > for more details. Thanks a lot for your review Petr, it is much appreciated! No need for apologies, there is no urgency here =) > [...] > This talks only about kdump. The reality is much more complicated. > The level affect the order of: > > + notifiers vs. kdump > + notifiers vs. crash_dump > + crash_dump vs. kdump First of all, I'd like to ask you please to clarify to me *exactly* what are the differences between "crash_dump" and "kdump". I'm sorry if that's a silly question, I need to be 100% sure I understand the concepts the same way you do. > There might theoretically many variants of the ordering of kdump, > crash_dump, and the 4 notifier list. Some variants do not make > much sense. You choose 5 variants and tried to select them by > a level number. > > The question is if we really could easily describe the meaning this > way. It is not only about a "level" of notifiers before kdump. It is > also about the ordering of crash_dump vs. kdump. IMHO, "level" > semantic does not fit there. > > Maybe more parameters might be easier to understand the effect. > Anyway, we first need to agree on the chosen variants. > I am going to discuss it more in the code, see below. > > > [...] > Here is the code using the above functions. It helps to discuss > the design and logic. > > > order_panic_notifiers_and_kdump(); > > /* If no level, we should kdump ASAP. */ > if (!panic_notifiers_level) > __crash_kexec(NULL); > > crash_smp_send_stop(); > panic_notifier_hypervisor_once(buf); > > if (panic_notifier_info_once(buf)) > kmsg_dump(KMSG_DUMP_PANIC); > > panic_notifier_pre_reboot_once(buf); > > __crash_kexec(NULL); > > panic_notifier_hypervisor_once(buf); > > if (panic_notifier_info_once(buf)) > kmsg_dump(KMSG_DUMP_PANIC); > > panic_notifier_pre_reboot_once(buf); > > > I have to say that the logic is very unclear. Almost all > functions are called twice: > >+ __crash_kexec() >+ kmsg_dump() >+ panic_notifier_hypervisor_once() >+ panic_notifier_pre_reboot_once() >+ panic_notifier_info_once() > > It is pretty hard to find what functions are always called in the same > order and where the order can be inverted. > > The really used code path is defined by order_panic_notifiers_and_kdump() > that encodes "level" into "bits". The bits are then flipped in > panic_notifier_*_once() calls that either do something or not. > kmsg_dump() is called according to the bit flip. > > It is an interesting approach. I guess that you wanted to avoid too > many if/then/else levels in panic(). But honestly, it looks like > a black magic to me. > > IMHO, it is always easier to follow if/then/else logic than using > a translation table that requires additional bit flips when > a value is used more times. > > Also I guess that it is good proof that "level" abstraction does > not fit here. Normal levels would not need this kind of magic. Heheh OK, I appreciate your opinion, but I guess we'll need to agree in disagree here - I'm much more fond to this kind of code than a bunch of if/else blocks that almost give headaches. Encoding such "level" logic in the if/else scheme is very convoluted, generates a very big code. And the functions aren't so black magic - they map a level in bits, and the functions _once() are called...once! Although we switch the position in the code, so there are 2 calls, one of them is called and the other not. But that's totally fine to change - especially if we're moving away from the "level" logic. I see below you propose a much simpler approach - if we follow that, definitely we won't need the "black magic" approach heheh > > OK, the question is how to make it better. Let's start with > a clear picture of the problem: > > 1. panic() has basically two funtions: > > + show/store debug information (optional ways and amount) > + do something with the system (reboot, stay hanged) > > > 2. There are 4 ways how to show/store the information: > > + tell hypervisor to store what it is interested about > + crash_dump > + kmsg_dump() > + consoles > > , where crash_dump and consoles are special: > > + crash_dump does not return. Instead it ends up with reboot. > > + Consoles work transparently. They just need an extra flush >before reboot or staying hanged. > > > 3. The various notifiers do things like: > > + tell hypervisor about the crash > + print more info
Re: [PATCH 11/30] um: Improve panic notifiers consistency and ordering
On 13/05/2022 11:44, Johannes Berg wrote: > [...] >> Maybe Anton / Johannes / Richard could give their opinions - appreciate >> that, I'm not attached to the priority here, it's more about users' >> common usage of UML I can think of... > > It's hard to say ... In a sense I'm not sure it matters? > > OTOH something like the ftrace dump notifier (kernel/trace/trace.c) > might still be useful to run before the mconsole and coredump ones, even > if you could probably use gdb to figure out the information. > > Personally, I don't have a scenario where I'd care about the trace > buffers though, and most of the others I found would seem irrelevant > (drivers that aren't even compiled, hung tasks won't really happen since > we exit immediately, and similar.) > > johannes Thanks Johannes, I agree with you. We don't have great ordering now, one thing we need to enforce is the order between the 2 UML notifiers, and this patch is doing that..trying to order against other callbacks like the ftrace dumper is messy in the current code. OTOH if this patch set is accepted at some point, we'll likely have 3 lists, and with that we can improve ordering a lot - this notifier for instance would run in the pre-reboot list, *after* the ftrace dumper (if a kmsg dumper is set). So, my intention is to keep this patch as is for V2 (with some changes Johannes suggested before), unless Petr or the other maintainers want something different. Cheers, Guilherme
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.18-5 tag
The pull request you sent on Sun, 15 May 2022 21:57:18 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.18-5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bc403203d65a874df2f3156046468052e4109cb0 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] Please pull powerpc/linux.git powerpc-5.18-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull another powerpc fix for 5.18: The following changes since commit 348c71344111d7a48892e3e52264ff11956fc196: powerpc/papr_scm: Fix buffer overflow issue with CONFIG_FORTIFY_SOURCE (2022-05-06 12:44:03 +1000) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.18-5 for you to fetch changes up to ee8348496c77e3737d0a6cda307a521f2cff954f: KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context() (2022-05-11 23:03:16 +1000) - -- powerpc fixes for 5.18 #5 - Fix KVM PR on 32-bit, which was broken by some MMU code refactoring. Thanks to: Alexander Graf, Matt Evans. - -- Alexander Graf (1): KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context() arch/powerpc/kvm/book3s_32_sr.S | 26 1 file changed, 21 insertions(+), 5 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmKA6GsACgkQUevqPMjh pYB76A//fuV++okA+VBke3SwWOcZGg/0Wc78zv/k7+dYpRr3FTthFZQpiGH+Nfq3 xJAfzG/b72P2u/20tCVFsIYrNQzhsTZ7aui0c9fDtYIyw/ejpkaspmU/OB41DhMb iumELPB9ZBaTgPSuxEeQ4O5oixW/WHO/QF8UdaaPqntiTsC1lH0hV70kqA+WQ7eh Zw3KHPt2KUR34ib99PRsxE4eoIq7Qf8IjPN0oJaFRZkyRCJE03KPC9VQAmGZCe5j uwfawFs36fSHuiJhBUfUzalCZmu54DkVzwI989GvuVfpZ08rW98eyCG9gAnWq0AU uKz0oPqlyM+QA6n7iLsdM7LNZ5iFZjE18oor518NHzAOJtZuuXEF3T/V7PNs2tKG Svzj16DtYrVNmXEJLkrtDPm3P3+jaw12+631Jh+uE4IkLP8o3cI4p/uo995vXb2K a2cFm0hg2qMMMjE2fjrXS8xaJr7wGFInLz0/RNbCtCIT70+gcnkrdlo785kCFsNX wDo/OaDvFA/pYYL1BTUeruUlQA/pAsm0danGJ99gFVOwJ9kd/bS6SV7yuB66uKpD d+qJXETAF3XvJAodXLRrUqeiTDDsFwa5d/kQ6L7EVqpHUV6jvInhdZgIwHEuQUf0 QYddYvl6nWa1C5QSGeKZ00ooSy1Swe0jpHfwWB3ooCZGfo+/mTE= =fNSB -END PGP SIGNATURE-
Re: [PATCH v3] KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()
On Tue, 10 May 2022 14:37:17 +0200, Alexander Graf wrote:
> Commit 863771a28e27 ("powerpc/32s: Convert switch_mmu_context() to C")
> moved the switch_mmu_context() to C. While in principle a good idea, it
> meant that the function now uses the stack. The stack is not accessible
> from real mode though.
>
> So to keep calling the function, let's turn on MSR_DR while we call it.
> That way, all pointer references to the stack are handled virtually.
>
> [...]
Applied to powerpc/fixes.
[1/1] KVM: PPC: Book3S PR: Enable MSR_DR for switch_mmu_context()
https://git.kernel.org/powerpc/c/ee8348496c77e3737d0a6cda307a521f2cff954f
cheers
Re: [PATCH v2 0/3] powerpc: Remove system call emulation
On Wed, 30 Mar 2022 19:37:16 +0530, Naveen N. Rao wrote: > Since v1, the main change is to use helpers to decode primary/extended > opcode and the addition of macros for some of the used opcodes. > > - Naveen > > > > [...] Applied to powerpc/next. [1/3] powerpc: Sort and de-dup primary opcodes in ppc-opcode.h https://git.kernel.org/powerpc/c/f31c618373f2051a32e30002d8eacad7bbbd3885 [2/3] powerpc: Reject probes on instructions that can't be single stepped https://git.kernel.org/powerpc/c/54cdacd7d3b3c1a8dc10965f56c8b5eb8eda1a33 [3/3] powerpc/64: remove system call instruction emulation https://git.kernel.org/powerpc/c/a553476c44fb6bd3dc3a7e5efef8f130f0f34850 cheers
Re: [PATCH v3] powerpc/rtas: Keep MSR[RI] set when calling RTAS
On Wed, 4 May 2022 12:12:44 +0200, Laurent Dufour wrote: > RTAS runs in real mode (MSR[DR] and MSR[IR] unset) and in 32bits > big endian mode (MSR[SF,LE] unset). > > The change in MSR is done in enter_rtas() in a relatively complex way, > since the MSR value could be hardcoded. > > Furthermore, a panic has been reported when hitting the watchdog interrupt > while running in RTAS, this leads to the following stack trace: > > [...] Applied to powerpc/next. [1/1] powerpc/rtas: Keep MSR[RI] set when calling RTAS https://git.kernel.org/powerpc/c/b6b1c3ce06ca438eb24e0f45bf0e63ecad0369f5 cheers
Re: [PATCH] powerpc: fix typos in comments
On Sat, 30 Apr 2022 20:56:54 +0200, Julia Lawall wrote: > Various spelling mistakes in comments. > Detected with the help of Coccinelle. > > Applied to powerpc/next. [1/1] powerpc: fix typos in comments https://git.kernel.org/powerpc/c/1fd02f6605b855b4af2883f29a2abc88bdf17857 cheers
Re: [PATCH v2 1/5] powerpc/8xx: Move CPM interrupt controller into a dedicated file
On Wed, 6 Apr 2022 08:23:17 +0200, Christophe Leroy wrote: > CPM interrupt controller is quite standalone. Move it into a > dedicated file. It will help for next step which will change > it to a platform driver. > > This is pure code move, checkpatch report is ignored at this point, > except one parenthesis alignment which would remain at the end of > the series. All other points fly away with following patches. > > [...] Applied to powerpc/next. [1/5] powerpc/8xx: Move CPM interrupt controller into a dedicated file https://git.kernel.org/powerpc/c/acf9e575d889eb8806be2c8451e7ad12bf444b50 [2/5] powerpc/8xx: Convert CPM1 error interrupt handler to platform driver https://git.kernel.org/powerpc/c/22add2a20e968291251d46d1b833b651b6aba5d7 [3/5] powerpc/8xx: Convert CPM1 interrupt controller to platform_device https://git.kernel.org/powerpc/c/14d893fc6846892ae68f8b259594d9cdae99e515 [4/5] powerpc/8xx: Remove mpc8xx_pics_init() https://git.kernel.org/powerpc/c/e3ba31b78074bee155662edccd9ca00324087e04 [5/5] powerpc/8xx: Use kmalloced data structure instead of global static https://git.kernel.org/powerpc/c/5ad1aa007da5f1907673a7cbfdf6e355835ef428 cheers
Re: [PATCH v1] powerpc: Use static call for get_irq()
On Fri, 11 Mar 2022 13:38:04 +0100, Christophe Leroy wrote: > __do_irq() inconditionnaly calls ppc_md.get_irq() > > That's definitely a hot path. > > At the time being ppc_md.get_irq address is read every time > from ppc_md structure. > > [...] Applied to powerpc/next. [1/1] powerpc: Use static call for get_irq() https://git.kernel.org/powerpc/c/e59596a2d6a75ea3deb60698b95942aaf03681f5 cheers
Re: [PATCH v1 1/6] powerpc/64: Move pci_device_from_OF_node() out of asm/pci-bridge.h
On Tue, 8 Mar 2022 20:20:20 +0100, Christophe Leroy wrote: > Move pci_device_from_OF_node() in pci64.c because it needs definition > of struct device_node and is not worth inlining. > > ppc32.c already has it in pci32.c. > > That way pci-bridge.h doesn't need linux/of.h (Brought by asm/prom.h > via asm/pci.h) > > [...] Applied to powerpc/next. [1/6] powerpc/64: Move pci_device_from_OF_node() out of asm/pci-bridge.h https://git.kernel.org/powerpc/c/0aa297e73bba35bedadbd2d452c62d643dfd4a32 [2/6] powerpc: Don't include asm/prom.h in asm/parport.h https://git.kernel.org/powerpc/c/07071346bb76f4fbc2c1ca8894ec3d3ad2f22577 [3/6] powerpc: Include asm/reg.h in asm/svm.h https://git.kernel.org/powerpc/c/eb4713c40a619046af99586743d48b9b4435d371 [4/6] powerpc: Add missing declaration in asm/drmem.h https://git.kernel.org/powerpc/c/669df99c957561dddf580ec269fb4255c41dabc1 [5/6] powerpc: Remove asm/prom.h from all files that don't need it https://git.kernel.org/powerpc/c/86c38fec69a461846d84f250f281e8cfbe54b25a [6/6] powerpc: Add missing headers https://git.kernel.org/powerpc/c/e6f6390ab7b9d649c13de2c8a591bce61a10ec3b cheers
Re: [PATCH v1 0/4] Kill the time spent in patch_instruction()
On Tue, 22 Mar 2022 16:40:17 +0100, Christophe Leroy wrote: > This series reduces by 70% the time required to activate > ftrace on an 8xx with CONFIG_STRICT_KERNEL_RWX. > > Measure is performed in function ftrace_replace_code() using mftb() > around the loop. > > With the series, > - Without CONFIG_STRICT_KERNEL_RWX, 416000 TB ticks are measured. > - With CONFIG_STRICT_KERNEL_RWX, 546000 TB ticks are measured. > > [...] Patches 1, 3 and 4 applied to powerpc/next. [1/4] powerpc/code-patching: Don't call is_vmalloc_or_module_addr() without CONFIG_MODULES https://git.kernel.org/powerpc/c/cb3ac45214c03852430979a43180371a44b74596 [3/4] powerpc/code-patching: Use jump_label for testing freed initmem https://git.kernel.org/powerpc/c/b033767848c4115e486b1a51946de3bee2ac0fa6 [4/4] powerpc/code-patching: Use jump_label to check if poking_init() is done https://git.kernel.org/powerpc/c/1751289268ef959db68b0b6f798d904d6403309a cheers
Re: [PATCH v10 00/13] Convert powerpc to default topdown mmap layout (v10)
On Sat, 9 Apr 2022 19:17:24 +0200, Christophe Leroy wrote: > Rebased on top of v5.18-rc1 > > This series converts powerpc to default topdown mmap layout. > > First patch is a mm fix that should go into v5.18 and stable. > > Andrew, can you take it ? > > [...] Patches 2-13 applied to powerpc/next. [02/13] mm: Allow arch specific arch_randomize_brk() with CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT https://git.kernel.org/powerpc/c/723820f3f77dc9f7ffdceb076ebcf6a5b91d0a27 [03/13] mm, hugetlbfs: Allow an arch to always use generic versions of get_unmapped_area functions https://git.kernel.org/powerpc/c/4b439e25e29ec336c0e71ef1d1b212c412526518 [04/13] mm: Add len and flags parameters to arch_get_mmap_end() https://git.kernel.org/powerpc/c/2cb4de085f383cb9289083d1bedbaad046f640eb [05/13] powerpc/mm: Move vma_mmu_pagesize() https://git.kernel.org/powerpc/c/93ea910295cae7ad69571ed1570e5b5ca54a2f9e [06/13] powerpc/mm: Make slice specific to book3s/64 https://git.kernel.org/powerpc/c/1408fca0c198471a5cd089742b9d3f9739073483 [07/13] powerpc/mm: Remove CONFIG_PPC_MM_SLICES https://git.kernel.org/powerpc/c/f693d38d9468101587175b1e62d7e4483b51d8f5 [08/13] powerpc/mm: Use generic_get_unmapped_area() and call it from arch_get_unmapped_area() https://git.kernel.org/powerpc/c/76a345ed16c63df9b02d3e374e8d5e39471174ad [09/13] powerpc/mm: Use generic_hugetlb_get_unmapped_area() https://git.kernel.org/powerpc/c/1a0261fd3b218b6999f38dc791a66c9b7ddc7e8b [10/13] powerpc/mm: Move get_unmapped_area functions to slice.c https://git.kernel.org/powerpc/c/ab57bd7570d4393beb5a91bf092ed54e9c3574a2 [11/13] powerpc/mm: Enable full randomisation of memory mappings https://git.kernel.org/powerpc/c/5cf7f9a0a54e93a6d3361de5f4ba4358b054c6c2 [12/13] powerpc/mm: Convert to default topdown mmap layout https://git.kernel.org/powerpc/c/36e5f9ee776cb6db6ab8cb9b056076c4492b9871 [13/13] powerpc: Simplify and move arch_randomize_brk() https://git.kernel.org/powerpc/c/3ba4289a3e7ff4a89a78c4f74d694a344e8d9cc9 cheers
Re: [PATCH] powerpc: Use rol32() instead of opencoding in csum_fold()
On Wed, 9 Mar 2022 08:56:14 +0100, Christophe Leroy wrote: > rol32(x, 16) will do the rotate using rlwinm. > > No need to open code using inline assembly. > > Applied to powerpc/next. [1/1] powerpc: Use rol32() instead of opencoding in csum_fold() https://git.kernel.org/powerpc/c/a1ae431705410fc7092790977bffd1b00c63c229 cheers
Re: [PATCH] powerpc: Reduce csum_add() complexity for PPC64
On Sat, 12 Feb 2022 08:36:17 +0100, Christophe Leroy wrote: > PPC64 does everything in C, gcc is able to skip calculation > when one of the operands in zero. > > Move the constant folding in PPC32 part. > > This helps GCC and reduces ppc64_defconfig by 170 bytes. > > [...] Applied to powerpc/next. [1/1] powerpc: Reduce csum_add() complexity for PPC64 https://git.kernel.org/powerpc/c/f206fdd9d41bf7deb96219b8ca3499a5abd79b83 cheers
Re: [PATCH] powerpc: align address to page boundary in change_page_attr()
On Mon, 21 Mar 2022 16:44:45 +0100, Christophe Leroy wrote: > Aligning address to page boundary allows flush_tlb_kernel_range() > to know it's a single page flush and use tlbie instead of tlbia. > > On 603 we now have the following code in first leg of > change_page_attr(): > > 2c: 55 29 00 3c rlwinm r9,r9,0,0,30 > 30: 91 23 00 00 stw r9,0(r3) > 34: 7c 00 22 64 tlbie r4,r0 > 38: 7c 00 04 ac hwsync > 3c: 38 60 00 00 li r3,0 > 40: 4e 80 00 20 blr > > [...] Applied to powerpc/next. [1/1] powerpc: align address to page boundary in change_page_attr() https://git.kernel.org/powerpc/c/65883b78bc9f49ac891bb202c59fcb76b9cfc611 cheers
Re: [PATCH] powerpc/8xx: Simplify flush_tlb_kernel_range()
On Mon, 21 Mar 2022 16:44:18 +0100, Christophe Leroy wrote:
> In the same spirit as commit 63f501e07a85 ("powerpc/8xx: Simplify TLB
> handling"), simplify flush_tlb_kernel_range() for 8xx.
>
> 8xx cannot be SMP, and has 'tlbie' and 'tlbia' instructions, so
> an inline version of flush_tlb_kernel_range() for 8xx is worth it.
>
> With this page, first leg of change_page_attr() is:
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/8xx: Simplify flush_tlb_kernel_range()
https://git.kernel.org/powerpc/c/9290c379d19774d8de6e2b895d756004dbad9ce5
cheers
Re: [PATCH] macintosh: Prepare cleanup of powerpc's asm/prom.h
On Fri, 1 Apr 2022 19:15:53 +0200, Christophe Leroy wrote: > powerpc's asm/prom.h brings some headers that it doesn't > need itself. > > In order to clean it up, first add missing headers in > users of asm/prom.h > > > [...] Applied to powerpc/next. [1/1] macintosh: Prepare cleanup of powerpc's asm/prom.h https://git.kernel.org/powerpc/c/a486e512d1f3fb93b0406ab125f35777d22b47ba cheers
Re: [PATCH] cxl/ocxl: Prepare cleanup of powerpc's asm/prom.h
On Sat, 2 Apr 2022 11:52:33 +0200, Christophe Leroy wrote: > powerpc's asm/prom.h brings some headers that it doesn't > need itself. > > In order to clean it up, first add missing headers in > users of asm/prom.h > > > [...] Applied to powerpc/next. [1/1] cxl/ocxl: Prepare cleanup of powerpc's asm/prom.h https://git.kernel.org/powerpc/c/d8d2af70b98109418bb16ff6638d7c1c4336f7fe cheers
Re: [PATCH kernel v3] powerpc/boot: Stop using RELACOUNT
On Wed, 6 Apr 2022 17:00:38 +1000, Alexey Kardashevskiy wrote:
> So far the RELACOUNT tag from the ELF header was containing the exact
> number of R_PPC_RELATIVE/R_PPC64_RELATIVE relocations. However the LLVM's
> recent change [1] make it equal-or-less than the actual number which
> makes it useless.
>
> This replaces RELACOUNT in zImage loader with a pair of RELASZ and RELAENT.
> The vmlinux relocation code is fixed in commit d79976918852
> ("powerpc/64: Add UADDR64 relocation support").
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot: Stop using RELACOUNT
https://git.kernel.org/powerpc/c/c14d31bae372e050b053f2511fb3f0f90c27e4f9
cheers
Re: [PATCH 3/6] powerpc/85xx: Fix virt_to_phys() off-by-one in smp_85xx_start_cpu()
On Thu, 7 Apr 2022 00:57:59 +1000, Michael Ellerman wrote: > In smp_85xx_start_cpu() we are passed an address but we're unsure if > it's a real or virtual address, so there's a check to determine that. > > [...] Applied to powerpc/next. [3/6] powerpc/85xx: Fix virt_to_phys() off-by-one in smp_85xx_start_cpu() https://git.kernel.org/powerpc/c/0d897255e79e26f471d10bbf72db9eee6f9cb723 cheers
Re: [PATCH v2 -next] powerpc/eeh: Remove unused inline functions
On Wed, 16 Mar 2022 18:42:39 +0800, YueHaibing wrote: > pseries_eeh_init_edev() is exclusively in eeh_pseries.c, > make it static and remove unused inline function. > pseries_eeh_init_edev_recursive() is only called from files build > wich CONFIG_HOTPLUG_PCI_RPA which depends on CONFIG_PSERIES and > CONFIG_EEH, so can remove the unused inline version. > > > [...] Applied to powerpc/next. [1/1] powerpc/eeh: Remove unused inline functions https://git.kernel.org/powerpc/c/f06351f8c0c85e2d53e73c53a33b4ef55b4ad6de cheers
Re: [PATCH v2] POWERPC: idle: fix return value of __setup handler
On Mon, 2 May 2022 12:29:25 -0700, Randy Dunlap wrote: > __setup() handlers should return 1 to obsolete_checksetup() in > init/main.c to indicate that the boot option has been handled. > A return of 0 causes the boot option/value to be listed as an Unknown > kernel parameter and added to init's (limited) argument or environment > strings. Also, error return codes don't mean anything to > obsolete_checksetup() -- only non-zero (usually 1) or zero. > So return 1 from powersave_off(). > > [...] Applied to powerpc/next. [1/1] POWERPC: idle: fix return value of __setup handler https://git.kernel.org/powerpc/c/b793a01000122d2bd133ba451a76cc135b5e162c cheers
Re: [PATCH v2] powerpc/4xx: cpm: fix return value of __setup handler
On Mon, 2 May 2022 12:29:41 -0700, Randy Dunlap wrote: > __setup() handlers should return 1 to obsolete_checksetup() in > init/main.c to indicate that the boot option has been handled. > A return of 0 causes the boot option/value to be listed as an Unknown > kernel parameter and added to init's (limited) argument or environment > strings. Also, error return codes don't mean anything to > obsolete_checksetup() -- only non-zero (usually 1) or zero. > So return 1 from cpm_powersave_off(). > > [...] Applied to powerpc/next. [1/1] powerpc/4xx: cpm: fix return value of __setup handler https://git.kernel.org/powerpc/c/5bb99fd4090fe1acfdb90a97993fcda7f8f5a3d6 cheers
Re: [PATCH] selftests/powerpc: Add a test of 4PB SLB handling
On Fri, 18 Mar 2022 01:39:25 +1100, Michael Ellerman wrote:
> Add a test for a bug we had in the 4PB address space SLB handling. It
> was fixed in commit 4c2de74cc869 ("powerpc/64: Interrupts save PPR on
> stack rather than thread_struct").
>
>
Applied to powerpc/next.
[1/1] selftests/powerpc: Add a test of 4PB SLB handling
https://git.kernel.org/powerpc/c/e96a76ee5283d509f2bf45133d147e77f73a1b15
cheers
Re: [PATCH] powerpc/boot: Build wrapper for an appropriate CPU
On Wed, 30 Mar 2022 21:54:37 +1030, Joel Stanley wrote: > Currently the boot wrapper lacks a -mcpu option, so it will be built for > the toolchain's default cpu. This is a problem if the toolchain defaults > to a cpu with newer instructions. > > We could wire in TARGET_CPU but instead use the oldest supported option > so the wrapper runs anywhere. > > [...] Applied to powerpc/next. [1/1] powerpc/boot: Build wrapper for an appropriate CPU https://git.kernel.org/powerpc/c/40a75584e526cc489234dac0897cd599e6013483 cheers
Re: (subset) [PATCH 0/7] Remove unused SLOW_DOWN_IO
On Fri, 15 Apr 2022 14:08:10 -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas > > Only alpha, ia64, powerpc, and sh define SLOW_DOWN_IO, and there are no > actual uses of it. The few references to it are in situations that are > themselves unused. Remove them all. > > It should be safe to apply these independently and in any order. The only > place SLOW_DOWN_IO is used at all is the lmc_var.h definition of DELAY, > which is itself never used. > > [...] Applied to powerpc/next. [5/7] powerpc: Remove unused SLOW_DOWN_IO definition https://git.kernel.org/powerpc/c/755a9d44e6e2a217cceaab9fe2c8bac55ee7f8b2 cheers
Re: [PATCH] misc: ocxl: fix possible double free in ocxl_file_register_afu
On Mon, 18 Apr 2022 16:57:58 +0800, Hangyu Hua wrote: > info_release() will be called in device_unregister() when info->dev's > reference count is 0. So there is no need to call ocxl_afu_put() and > kfree() again. > > Fix this by adding free_minor() and return to err_unregister error path. > > > [...] Applied to powerpc/next. [1/1] misc: ocxl: fix possible double free in ocxl_file_register_afu https://git.kernel.org/powerpc/c/950cf957fe34d40d63dfa3bf3968210430b6491e cheers
Re: [PATCH] powerpc/fadump: save CPU reg data in vmcore when PHYP terminates LPAR
On Mon, 4 Apr 2022 23:51:37 +0530, Hari Bathini wrote: > An LPAR can be terminated by the POWER Hypervisor (PHYP) for various > reasons. If FADump was configured when PHYP terminates the LPAR, > platform-assisted dump is initiated to save the kernel dump. But CPU > register data would not be processed/saved in the vmcore in such case > because CPU mask is set in crash_fadump() at the time of kernel crash > and it remains unset in this case with LPAR being terminated by PHYP > abruptly. > > [...] Applied to powerpc/next. [1/1] powerpc/fadump: save CPU reg data in vmcore when PHYP terminates LPAR https://git.kernel.org/powerpc/c/6584cec0a2255ab407d047d1b135fa0aae88d6c6 cheers
Re: [PATCH] opal/fadump: fix fadump to work with a different endian capture kernel
On Wed, 21 Apr 2021 23:20:52 +0530, Hari Bathini wrote: > Dump capture would fail if capture kernel is not of the endianess as > the production kernel, because the in-memory data structure (struct > opal_fadump_mem_struct) shared across production kernel and capture > kernel assumes the same endianess for both the kernels, which doesn't > have to be true always. Fix it by having a well-defined endianess for > struct opal_fadump_mem_struct. > > [...] Applied to powerpc/next. [1/1] opal/fadump: fix fadump to work with a different endian capture kernel https://git.kernel.org/powerpc/c/b74196af372f7cb4902179009265fe63ac81824f cheers
Re: [PATCH 0/3] powerpc/fadump: fadump fixes and improvements
On Wed, 6 Apr 2022 15:08:36 +0530, Hari Bathini wrote: > This series fixes a couple of issues in fadump and improves logging. > The first patch fixes a bug that is observed when memory reserved for > fadump is not adjacent to boot memory area. The second patch ensures > mmap read succeeds for all memory regions in the vmcore. The third > patch improves the data that is printed for fadump. > > Hari Bathini (3): > powerpc/fadump: fix PT_LOAD segment for boot memory area > powerpc/fadump: align destination address to pagesize > powerpc/fadump: print start of preserved area > > [...] Applied to powerpc/next. [1/3] powerpc/fadump: fix PT_LOAD segment for boot memory area https://git.kernel.org/powerpc/c/15eb77f873255cf9f4d703b63cfbd23c46579654 [2/3] powerpc/fadump: align destination address to pagesize https://git.kernel.org/powerpc/c/9cf3b3a33a36ef4a988be0a770edd3555297f2a9 [3/3] powerpc/fadump: print start of preserved area https://git.kernel.org/powerpc/c/a3ceb5882edf6696ebc6aeb8043ddec548a93052 cheers
Re: [PATCH 1/1] powerpc/boot: remove unused function find_node_by_linuxphandle()
On Sun, 24 Apr 2022 13:40:14 -0500, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> The last user of find_node_by_linuxphandle() was removed in v4.18-rc1
> by commit 30f4bbe0472a ("powerpc/boot: Remove support for Marvell MPSC serial
> controller")
> four years ago. This function is no longer needed.
>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/boot: remove unused function find_node_by_linuxphandle()
https://git.kernel.org/powerpc/c/2fb70d1d36e2f8482a78bb8aae688ae1416af889
cheers
Re: [PATCH v1 1/1] powerpc/83xx/mpc8349emitx: Get rid of of_node assignment
On Wed, 23 Mar 2022 19:43:42 +0200, Andy Shevchenko wrote: > Let GPIO library to assign of_node from the parent device. > This allows to move GPIO library and drivers to use fwnode > APIs instead of being stuck with OF-only interfaces. > > Applied to powerpc/next. [1/1] powerpc/83xx/mpc8349emitx: Get rid of of_node assignment https://git.kernel.org/powerpc/c/610cc9f45881f1a3758f323d6d7d67e572958c3b cheers
Re: [PATCH] selftests/powerpc/pmu: Fix unsigned function returning negative constant
On Sun, 24 Apr 2022 16:26:41 +0800, Haowen Bai wrote: > The function __perf_reg_mask has an unsigned return type, but returns a > negative constant to indicate an error condition. So we change unsigned > to int. > > Applied to powerpc/next. [1/1] selftests/powerpc/pmu: Fix unsigned function returning negative constant https://git.kernel.org/powerpc/c/a84ca704d8306a949578d36c028c8e1bab3dcf0b cheers
Re: [PATCH] selftests/powerpc: Add matrix multiply assist (MMA) test
On Mon, 22 Jun 2020 12:18:32 +1000, Alistair Popple wrote: > Adds a simple test of some basic matrix multiply assist (MMA) > instructions. > > Applied to powerpc/next. [1/1] selftests/powerpc: Add matrix multiply assist (MMA) test https://git.kernel.org/powerpc/c/3527e1ab9a7990530dfb0137ddcfa64bed2915be cheers
Re: [PATCH 0/3] KASAN support for 64-bit Book 3S powerpc
Le 11/05/2022 à 09:25, Paul Mackerras a écrit : > [Vous ne recevez pas souvent de courriers de la part de pau...@ozlabs.org. > D?couvrez pourquoi cela peut ?tre important ? l'adresse > https://aka.ms/LearnAboutSenderIdentification.] > > This patch series implements KASAN on 64-bit POWER with radix MMU, > such as POWER9 or POWER10. Daniel Axtens posted previous versions of > these patches, but is no longer working on KASAN, and I have been > asked to get them ready for inclusion. > > Because of various technical difficulties, mostly around the need to > allow for code that runs in real mode, we only support "outline" mode > (as opposed to "inline" mode), where the compiler adds a call to > a checking procedure before every store to memory. > > The main patch is still marked [RFC] because of known deficiencies, > specifically that the kernel will crash on boot on a HPT system, and > that out-of-bounds accesses to module global data are not caught > (which leads to one of the KASAN tests failing). > > Comments welcome. I may not have addressed all the comments about > previous versions of these patches; if so, then please just repeat > your comments. Last patch is quite big. I think it would be worth splitting in several patches. A made a few suggestions while reviewing it. I think it could also be worth putting all the adding of no_instr and KASAN_SANITIZE := n in a preparatory patch. Also, your last patch includes v1 of "powerpc: make stack walking KASAN-safe" (https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210528074806.1311297-1-...@axtens.net/) while v2 was merged (https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210614120907.1952321-1-...@axtens.net/) Christophe
Re: [PATCH 3/3] [RFC] powerpc: Book3S 64-bit outline-only KASAN support
Le 11/05/2022 à 09:28, Paul Mackerras a écrit :
> From: Daniel Axtens
>
> Implement a limited form of KASAN for Book3S 64-bit machines running under
> the Radix MMU, supporting only outline mode.
>
> - Enable the compiler instrumentation to check addresses and maintain the
> shadow region. (This is the guts of KASAN which we can easily reuse.)
>
> - Require kasan-vmalloc support to handle modules and anything else in
> vmalloc space.
>
> - KASAN needs to be able to validate all pointer accesses, but we can't
> instrument all kernel addresses - only linear map and vmalloc. On boot,
> set up a single page of read-only shadow that marks all iomap and
> vmemmap accesses as valid.
>
> - Document KASAN in both generic and powerpc docs.
>
> Background
> --
>
> KASAN support on Book3S is a bit tricky to get right:
>
> - It would be good to support inline instrumentation so as to be able to
> catch stack issues that cannot be caught with outline mode.
>
> - Inline instrumentation requires a fixed offset.
>
> - Book3S runs code with translations off ("real mode") during boot,
> including a lot of generic device-tree parsing code which is used to
> determine MMU features.
>
> [ppc64 mm note: The kernel installs a linear mapping at effective
> address c000...-c008 This is a one-to-one mapping with physical
> memory from ... onward. Because of how memory accesses work on
> powerpc 64-bit Book3S, a kernel pointer in the linear map accesses the
> same memory both with translations on (accessing as an 'effective
> address'), and with translations off (accessing as a 'real
> address'). This works in both guests and the hypervisor. For more
> details, see s5.7 of Book III of version 3 of the ISA, in particular
> the Storage Control Overview, s5.7.3, and s5.7.5 - noting that this
> KASAN implementation currently only supports Radix.]
>
> - Some code - most notably a lot of KVM code - also runs with translations
> off after boot.
>
> - Therefore any offset has to point to memory that is valid with
> translations on or off.
>
> One approach is just to give up on inline instrumentation. This way
> boot-time checks can be delayed until after the MMU is set is up, and we
> can just not instrument any code that runs with translations off after
> booting. Take this approach for now and require outline instrumentation.
>
> Previous attempts allowed inline instrumentation. However, they came with
> some unfortunate restrictions: only physically contiguous memory could be
> used and it had to be specified at compile time. Maybe we can do better in
> the future.
>
> [pau...@ozlabs.org - Rebased onto 5.17. Still RFC because:
>
> (a) A kernel with CONFIG_KASAN=y will crash during boot on a machine
> using HPT translation because not all the entry points to the generic
> KASAN code are protected with a call to kasan_arch_is_ready() -- at
> least __kasan_kfree_large() and __kasan_check_byte() need such a
> guard, and probably others. Previous versions of this code had a
> panic() call in kasan_init() to prevent a KASAN-enabled kernel from
> booting on a HPT machine, but unfortunately the panic string doesn't
> actually get printed to the console, because kasan_init gets called
> very early.
>
> (b) Of the KASAN tests included in the kernel source, all the
> relevant ones pass except for the "global_oob_right" test, and it
> only fails when CONFIG_KASAN_KUNIT_TEST=m; it passes when the kunit
> tests are built in. That is, KASAN is not detecting out-of-bounds
> accesses to module-global data.
> ]
>
> Originally-by: Balbir Singh # ppc64 out-of-line radix
> version
> Signed-off-by: Daniel Axtens
> Signed-off-by: Paul Mackerras
> ---
> Documentation/dev-tools/kasan.rst| 11 +-
> Documentation/powerpc/kasan.txt | 48 -
> arch/powerpc/Kconfig | 5 +-
> arch/powerpc/Kconfig.debug | 3 +-
> arch/powerpc/include/asm/book3s/64/hash.h| 4 +
> arch/powerpc/include/asm/book3s/64/pgtable.h | 3 +
> arch/powerpc/include/asm/book3s/64/radix.h | 13 ++-
> arch/powerpc/include/asm/interrupt.h | 52 +++---
> arch/powerpc/include/asm/kasan.h | 22
> arch/powerpc/include/asm/ptrace.h| 6 --
> arch/powerpc/kernel/Makefile | 11 ++
> arch/powerpc/kernel/process.c| 16 +--
> arch/powerpc/kernel/smp.c| 22 ++--
> arch/powerpc/kernel/traps.c | 6 +-
> arch/powerpc/kexec/Makefile | 2 +
> arch/powerpc/kvm/Makefile| 5 +
> arch/powerpc/lib/Makefile| 3 +
> arch/powerpc/mm/book3s64/Makefile| 9 ++
> arch/powerpc/mm/kasan/Makefile | 1 +
> arch/powerpc/mm/kasan/init_book3s_
