Re: [PATCH] powerpc: check previous kernel's ima-kexec-buffer against memory bounds
Michael Ellerman writes:
>
> Rob's point is that commit fee3ff99bc67 only moved existing code, the
> bug already existed.
>
> The function was introduced in:
>
> 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous
> kernel")
>
> So that's where the Fixes tag should point.
Thanks Mpe for explaining and apologies Rob as I initially didnt get the
point you made. I wrongly assumed that since the patch can only be
applied on top of commit fee3ff99bc67 hence fixes should point to
fee3ff99bc67.
I have sent out a v2 with the updated Fixes tag and also changes as
suggested by Mpe and Rob at
https://lore.kernel.org/all/20220524055042.1527968-1-vaib...@linux.ibm.com/
--
Cheers
~ Vaibhav
[PATCH v2] of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with 'mem=X' arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
BUG: Unable to handle kernel data access on read at 0xc000c01fff7f
Faulting instruction address: 0xc0837974
Oops: Kernel access of bad area, sig: 11 [#1]
NIP [c0837974] ima_restore_measurement_list+0x94/0x6c0
LR [c083b55c] ima_load_kexec_buffer+0xac/0x160
Call Trace:
[c371fa80] [c083b55c] ima_load_kexec_buffer+0xac/0x160
[c371fb00] [c20512c4] ima_init+0x80/0x108
[c371fb70] [c20514dc] init_ima+0x4c/0x120
[c371fbf0] [c0012240] do_one_initcall+0x60/0x2c0
[c371fcc0] [c2004ad0] kernel_init_freeable+0x344/0x3ec
[c371fda0] [c00128a4] kernel_init+0x34/0x1b0
[c371fe10] [c000ce64] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc0 40810330
7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010
---[ end trace ]---
Fix this issue by checking returned PFN range of previous kernel's
ima-kexec-buffer with pfn_valid to ensure correct memory bounds.
Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous
kernel")
Cc: Frank Rowand
Cc: Prakhar Srivastava
Cc: Lakshmi Ramasubramanian
Cc: Thiago Jung Bauermann
Cc: Rob Herring
Signed-off-by: Vaibhav Jain
---
Changelog
==
v2:
* Instead of using memblock to determine the valid bounds use pfn_valid() to do
so since memblock may not be available late after the kernel init. [ Mpe ]
* Changed the patch prefix from 'powerpc' to 'of' [ Mpe ]
* Updated the 'Fixes' tag to point to correct commit that introduced this
function. [ Rob ]
* Fixed some whitespace/tab issues in the patch description [ Rob ]
* Added another check for checking ig 'tmp_size' for ima-kexec-buffer is > 0
---
drivers/of/kexec.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 8d374cc552be..879e984fe901 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -126,6 +126,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
{
int ret, len;
unsigned long tmp_addr;
+ unsigned int start_pfn, end_pfn;
size_t tmp_size;
const void *prop;
@@ -140,6 +141,22 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
if (ret)
return ret;
+ /* Do some sanity on the returned size for the ima-kexec buffer */
+ if (!tmp_size)
+ return -ENOENT;
+
+ /*
+* Calculate the PFNs for the buffer and ensure
+* they are with in addressable memory.
+*/
+ start_pfn = PHYS_PFN(tmp_addr);
+ end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
+ if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn)) {
+ pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
+ tmp_addr, tmp_size);
+ return -EINVAL;
+ }
+
*addr = __va(tmp_addr);
*size = tmp_size;
--
2.35.1
[PATCH] powerpc/64s: Only set HAVE_ARCH_UNMAPPED_AREA when CONFIG_PPC_64S_HASH_MMU is set
When CONFIG_PPC_64S_HASH_MMU is not set, slice.c is not built and
arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
not provided because RADIX uses the generic ones.
Therefore, neither set HAVE_ARCH_UNMAPPED_AREA nor
HAVE_ARCH_UNMAPPED_AREA_TOPDOWN.
Reported-by: Laurent Dufour
Fixes: ab57bd7570d4 ("powerpc/mm: Move get_unmapped_area functions to slice.c")
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/slice.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
b/arch/powerpc/include/asm/book3s/64/slice.h
index b8eb4ad271b9..5fbe18544cbd 100644
--- a/arch/powerpc/include/asm/book3s/64/slice.h
+++ b/arch/powerpc/include/asm/book3s/64/slice.h
@@ -4,11 +4,13 @@
#ifndef __ASSEMBLY__
+#ifdef CONFIG_PPC_64S_HASH_MMU
#ifdef CONFIG_HUGETLB_PAGE
#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
#endif
#define HAVE_ARCH_UNMAPPED_AREA
#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
+#endif
#define SLICE_LOW_SHIFT28
#define SLICE_LOW_TOP (0x1ul)
--
2.35.3
[PATCH] powerpc/xics: Include missing header
Include of_adresses.h to get of_iomap() prototype.
Fixes: 86c38fec69a4 ("powerpc: Remove asm/prom.h from all files that don't need
it")
Signed-off-by: Christophe Leroy
---
arch/powerpc/sysdev/xics/ics-native.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/xics/ics-native.c
b/arch/powerpc/sysdev/xics/ics-native.c
index e33b77da861e..112c8a1e8159 100644
--- a/arch/powerpc/sysdev/xics/ics-native.c
+++ b/arch/powerpc/sysdev/xics/ics-native.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
--
2.35.3
Re: [PATCH] powerpc: Fix all occurences of "the the"
Michael Ellerman writes:
> Brian W Hart writes:
>> On Thu, May 19, 2022 at 12:26:29AM +1000, Michael Ellerman wrote:
>>> Rather than waiting for the bots to fix these one-by-one, fix all
>>> occurences of "the the" throughout arch/powerpc.
> ...
>>> diff --git a/arch/powerpc/platforms/chrp/setup.c
>>> b/arch/powerpc/platforms/chrp/setup.c
>>> index ef4c2b15f9dd..5d237da43b64 100644
>>> --- a/arch/powerpc/platforms/chrp/setup.c
>>> +++ b/arch/powerpc/platforms/chrp/setup.c
>>> @@ -253,7 +253,7 @@ static void __noreturn briq_restart(char *cmd)
>>> * Per default, input/output-device points to the keyboard/screen
>>> * If no card is installed, the built-in serial port is used as a fallback.
>>> * But unfortunately, the firmware does not connect /chosen/{stdin,stdout}
>>> - * the the built-in serial node. Instead, a /failsafe node is created.
>>> + * the built-in serial node. Instead, a /failsafe node is created.
>>> */
>>> static __init void chrp_init(void)
>>> {
>>
>> Maybe this one should be "to the"?
>
> You're right. Darn it, I've already applied the patch.
>
> Given how old this code is it will probably not last many more years, so
> I'll just leave it as-is. Hopefully no one writes a bot that looks for
> missing "to"s.
I did fix it in the end, because I needed to rebase to fix something else.
cheers
Re: linux-next: changed messages in qemu boot
"Naveen N. Rao" writes:
> Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next bboot of the powerpc pseries_le_defconfig build
>> produced these different kernel messages (diff from yesterday's tree):
>>
>> - ftrace: allocating 33658 entries in 13 pages
>> - ftrace: allocated 13 pages with 3 groups
>> + ftrace-powerpc: Address of ftrace_regs_caller out of range of kernel_toc.
>
> Thanks for the report. I think that is due to:
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/bb6626e884acffe87b58736291df57db3deaa9b9.1652074503.git.christophe.le...@csgroup.eu/
Yep, I bisected it there.
I should really read my email before bisecting :)
> The below diff fixes it for me:
>
> diff --git a/arch/powerpc/kernel/trace/ftrace.c
> b/arch/powerpc/kernel/trace/ftrace.c
> index 46c002a8388804..7418da705d43ac 100644
> --- a/arch/powerpc/kernel/trace/ftrace.c
> +++ b/arch/powerpc/kernel/trace/ftrace.c
> @@ -746,7 +746,7 @@ int __init ftrace_dyn_arch_init(void)
>
> reladdr = addr - kernel_toc_addr();
>
> - if (reladdr >= SZ_2G || reladdr < -SZ_2G) {
> + if (reladdr >= SZ_2G || reladdr < -_UL(SZ_2G)) {
> pr_err("Address of %ps out of range of kernel_toc.\n",
> (void *)addr);
> return -1;
I did:
if (reladdr >= SZ_2G || reladdr < -(long)SZ_2G) {
Which more closely matches what the old code did, and I think is more
obvious? ie. we don't want to negate the unsigned value, we want a
signed value, and then the negative of that.
cheers
[Bug 215803] ppc64le(P9): BUG: Kernel NULL pointer dereference on read at 0x00000060 NIP: do_remove_conflicting_framebuffers+0x184/0x1d0
https://bugzilla.kernel.org/show_bug.cgi?id=215803 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #6 from Michael Ellerman (mich...@ellerman.id.au) --- The fix was merged into v5.18-rc2 as: https://git.kernel.org/torvalds/c/0f525289ff0ddeb380813bd81e0f9bdaaa1c9078 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list
On 19/05/2022 16:20, Scott Branden wrote: > [...] >> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter >> designed to run in x86 only or you have other architectures' use cases? > The adapter may be used in any PCIe design that supports DMA. > So it may be possible to run in arm64 servers. >> >> [...] >> With that said, and given this is a lightweight notifier that ideally >> should run ASAP, I'd keep this one in the hypervisor list. We can >> "adjust" the semantic of this list to include lightweight notifiers that >> reset adapters. > Sounds the best to keep system operating as tested today. >> >> With that said, Petr has a point - not always such list is going to be >> called before kdump. So, that makes me think in another idea: what if we >> have another list, but not on panic path, but instead in the custom >> crash_shutdown()? Drivers could add callbacks there that must execute >> before kexec/kdump, no matter what. > It may be beneficial for some other drivers but for our use we would > then need to register for the panic path and the crash_shutdown path. > We notify the VK card for 2 purposes: one to stop DMA so memory stop > changing during a kdump. And also to get the card into a good state so > resets happen cleanly. Thanks Scott! With that, I guess it's really better to keep this notifier in this hypervisor/early list - I'm planning to do that for V2. Unless Petr or somebody has strong feelings against that, of course. Cheers, Guilherme
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
Hi Guenter, Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck: > On 5/23/22 08:18, Guo Ren wrote: > > I tested Palmer's branch, it's okay: > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a > > bogus mmu-type on a no MMU kernel > > > > I also tested linux-next, it's okay: > > > > rv64_rootfs: > > # uname -a > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT > > 2022 riscv64 GNU/Linux > > # > > That is is ok with one setup doesn't mean it is ok with > all setups. It is not ok with my root file system (from > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64), > with qemu v6.2. That is very true that it shouldn't fail on any existing (qemu-)platform, but as I remember also testing Guo's series on both riscv32 and riscv64 qemu platforms in the past, I guess it would be really helpful to get more information about the failing platform you're experiencing so that we can find the source of the issue. As it looks like you both tested the same kernel source, I guess the only differences could be in the qemu-version, kernel config and rootfs. Is your rootfs something you can share or that can be rebuilt easily? Heiko > > # > > # > > # ls /lib > > ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so > > ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 > > ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so > > libatomic.so libc.so.1modules > > > > My root file system uses musl. > > Guenter > > > rv32_rootfs: > > buildroot login: root > > # uname -a > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT > > 2022 riscv64 GNU/Linux > > # ls /lib > > ld-linux-riscv32-ilp32d.so.1 libm.so.6 > > libanl.so.1 libnss_dns.so.2 > > libatomic.so libnss_files.so.2 > > libatomic.so.1libpthread.so.0 > > libatomic.so.1.2.0libresolv.so.2 > > libc.so.6 librt.so.1 > > libcrypt.so.1 libthread_db.so.1 > > libdl.so.2libutil.so.1 > > libgcc_s.so modules > > libgcc_s.so.1 > > > > Here is my qemu version: > > commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> > > riscv-to-apply.next, alistair/riscv-to-apply.next) > > Author: Tsukasa OI > > Date: Sun May 15 11:56:11 2022 +0900 > > > > target/riscv: Move/refactor ISA extension checks > > > > We should separate "check" and "configure" steps as possible. > > This commit separates both steps except vector/Zfinx-related checks. > > > > Signed-off-by: Tsukasa OI > > Reviewed-by: Alistair Francis > > Message-Id: > > > > Signed-off-by: Alistair Francis > > > > On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > >> > >> On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > >>> From: Guo Ren > >>> > >>> Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > >>> 64bit S-mode) support. > >>> - Setup kconfig & dummy functions for compiling. > >>> - Implement compat_start_thread by the way. > >>> > >>> Signed-off-by: Guo Ren > >>> Signed-off-by: Guo Ren > >>> Reviewed-by: Arnd Bergmann > >>> Tested-by: Heiko Stuebner > >>> Cc: Palmer Dabbelt > >> > >> With this patch in linux-next, all my riscv64 emulations crash. > >> > >> [ 11.600082] Run /sbin/init as init process > >> [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x > >> in libc.so[ff8ad39000+a4000] > >> [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted > >> 5.18.0-rc7-next-20220520 #1 > >> [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > >> [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > >> 00ffc58199f0 > >> [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > >> > >> [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > >> 00ff8ade0cc0 > >> [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > >> 00ffc5819a00 > >> [ 11.629622] a2 : 0001 a3 : 001e a4 : > >> 00ffc5819b00 > >> [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > >> > >> [ 11.629645] s2 : 0
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On Tue, May 24, 2022 at 12:40:06AM +0200, Heiko Stübner wrote:
> Hi Guenter,
>
> Am Montag, 23. Mai 2022, 18:18:47 CEST schrieb Guenter Roeck:
> > On 5/23/22 08:18, Guo Ren wrote:
> > > I tested Palmer's branch, it's okay:
> > > 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a
> > > bogus mmu-type on a no MMU kernel
> > >
> > > I also tested linux-next, it's okay:
> > >
> > > rv64_rootfs:
> > > # uname -a
> > > Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT
> > > 2022 riscv64 GNU/Linux
> > > #
> >
> > That is is ok with one setup doesn't mean it is ok with
> > all setups. It is not ok with my root file system (from
> > https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64),
> > with qemu v6.2.
>
> That is very true that it shouldn't fail on any existing (qemu-)platform,
> but as I remember also testing Guo's series on both riscv32 and riscv64
> qemu platforms in the past, I guess it would be really helpful to get more
> information about the failing platform you're experiencing so that we can
> find the source of the issue.
>
> As it looks like you both tested the same kernel source, I guess the only
> differences could be in the qemu-version, kernel config and rootfs.
> Is your rootfs something you can share or that can be rebuilt easily?
>
I provided a link to my root file system above. The link points to two
root file systems, for initrd (cpio archive) and for ext2.
I also mentioned above that I used qemu v6.2. And below I said
> My root file system uses musl.
I attached the buildroot configuration below. The buildroot version,
if I remember correctly, was 2021.02.
Kernel configuration is basically defconfig. However, I do see one
detail that is possibly special in my configuration.
# The latest kernel assumes SBI version 0.3, but that doesn't match qemu
# at least up to version 6.2 and results in hangup/crashes during reboot
# with sifive_u emulations.
enable_config "${defconfig}" CONFIG_RISCV_SBI_V01
Hope that helps,
Guenter
---
BR2_riscv=y
BR2_TOOLCHAIN_BUILDROOT_MUSL=y
BR2_KERNEL_HEADERS_4_19=y
BR2_BINUTILS_VERSION_2_32_X=y
BR2_TARGET_RUN_TESTSCRIPT=y
BR2_SHUTDOWN_COMMAND_POWEROFF=y
BR2_SYSTEM_DHCP="eth0"
BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
BR2_PACKAGE_STRACE=y
BR2_PACKAGE_I2C_TOOLS=y
BR2_PACKAGE_PCIUTILS=y
BR2_PACKAGE_DTC=y
BR2_PACKAGE_DTC_PROGRAMS=y
BR2_PACKAGE_IPROUTE2=y
BR2_TARGET_ROOTFS_BTRFS=y
BR2_TARGET_ROOTFS_CPIO=y
BR2_TARGET_ROOTFS_CPIO_GZIP=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_SIZE="16M"
BR2_TARGET_ROOTFS_EXT2_GZIP=y
BR2_TARGET_ROOTFS_ISO_GZIP=y
BR2_TARGET_ROOTFS_SQUASHFS=y
# BR2_TARGET_ROOTFS_TAR is not set
Re: [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path
On 28/04/2022 13:55, Helge Deller wrote: > [...] > You may add: > Acked-by: Helge Deller # parisc > > Helge Hi Helge, do you think would be possible to still pick this one for v5.19 or do you prefer to hold for the next release? I'm working on V2, so if it's merged for 5.19 I won't send it again. Thanks, Guilherme
Re: [PATCH] net: fs_enet: sync rx dma buffer before reading
On Sat, 21 May 2022 10:44:30 -0700 Jakub Kicinski wrote: > > Well, I say the contrary. > > > > On the mainline the patch may be applied as is, it won't harm. > > > > However, it is gets applied to kernel 4.9 (based on the fixes: tag), it > > will break the driver for at least powerpc 8xx. > > I see, we should make a note of that in the commit message so it doesn't > get sucked into stable. > > > I don't know how SWIOTLB works or even what it is, does any of the > > microcontrollers embedding freescale ethernet uses that at all ? > > AFAIU SWIOTLB basically forces the use of bounce buffers even if the > device can reach the entire DRAM. I think some people also use it for > added security? IDK. I mostly use it to check if I'm using the DMA API > "right" :) If what I said makes sense please repost the patch, the current version has been dropped from patchwork already.
Re: [PATCH 0/5] kallsyms: make kallsym APIs more safe with scnprintf
On Sat, May 21, 2022 at 11:07:52PM -0700, Christoph Hellwig wrote: > On Fri, May 20, 2022 at 02:06:56PM +0530, Maninder Singh wrote: > > kallsyms functionality depends on KSYM_NAME_LEN directly. > > but if user passed array length lesser than it, sprintf > > can cause issues of buffer overflow attack. > > > > So changing *sprint* and *lookup* APIs in this patch set > > to have buffer size as an argument and replacing sprintf with > > scnprintf. > > This is still a pretty horrible API. Passing something like > a struct seq_buf seems like the much better API here. Also with > the amount of arguments and by reference passing it might be worth > to pass them as a structure while you're at it. Yeah, I agree. It really seems like seq_buf would be nicer. -- Kees Cook
[RFC PATCH 4/4] objtool/powerpc: Add --mcount specific implementation
This patch enables objtool --mcount on powerpc, and
adds implementation specific to powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig| 1 +
tools/objtool/arch/powerpc/decode.c | 14 ++
tools/objtool/check.c | 12 +++-
tools/objtool/elf.c | 13 +
tools/objtool/include/objtool/elf.h | 1 +
5 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 732a3f91ee5e..3373d44a1298 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -233,6 +233,7 @@ config PPC
select HAVE_NMI if PERF_EVENTS || (PPC64 &&
PPC_BOOK3S)
select HAVE_OPTPROBES
select HAVE_OBJTOOL if PPC64
+ select HAVE_OBJTOOL_MCOUNT if HAVE_OBJTOOL
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/tools/objtool/arch/powerpc/decode.c
b/tools/objtool/arch/powerpc/decode.c
index e3b77a6ce357..ad3d79fffac2 100644
--- a/tools/objtool/arch/powerpc/decode.c
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -40,12 +40,26 @@ int arch_decode_instruction(struct objtool_file *file,
const struct section *sec
struct list_head *ops_list)
{
u32 insn;
+ unsigned int opcode;
*immediate = 0;
memcpy(, sec->data->d_buf+offset, 4);
*len = 4;
*type = INSN_OTHER;
+ opcode = (insn >> 26);
+
+ switch (opcode) {
+ case 18: /* bl */
+ if ((insn & 3) == 1) {
+ *type = INSN_CALL;
+ *immediate = insn & 0x3fc;
+ if (*immediate & 0x200)
+ *immediate -= 0x400;
+ }
+ break;
+ }
+
return 0;
}
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 056302d58e23..fd8bad092f89 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -832,7 +832,7 @@ static int create_mcount_loc_sections(struct objtool_file
*file)
if (elf_add_reloc_to_insn(file->elf, sec,
idx * sizeof(unsigned long),
- R_X86_64_64,
+ elf_reloc_type_long(file->elf),
insn->sec, insn->offset))
return -1;
@@ -2183,7 +2183,7 @@ static int classify_symbols(struct objtool_file *file)
if (arch_is_retpoline(func))
func->retpoline_thunk = true;
- if (!strcmp(func->name, "__fentry__"))
+ if ((!strcmp(func->name, "__fentry__")) ||
(!strcmp(func->name, "_mcount")))
func->fentry = true;
if (is_profiling_func(func->name))
@@ -2259,9 +2259,11 @@ static int decode_sections(struct objtool_file *file)
* Must be before add_jump_destinations(), which depends on 'func'
* being set for alternatives, to enable proper sibling call detection.
*/
- ret = add_special_section_alts(file);
- if (ret)
- return ret;
+ if (opts.stackval || opts.orc || opts.uaccess || opts.noinstr) {
+ ret = add_special_section_alts(file);
+ if (ret)
+ return ret;
+ }
ret = add_jump_destinations(file);
if (ret)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index c25e957c1e52..95763060d551 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -793,6 +793,19 @@ elf_create_section_symbol(struct elf *elf, struct section
*sec)
return sym;
}
+int elf_reloc_type_long(struct elf *elf)
+{
+ switch (elf->ehdr.e_machine) {
+ case EM_X86_64:
+ return R_X86_64_64;
+ case EM_PPC64:
+ return R_PPC64_ADDR64;
+ default:
+ WARN("unknown machine...");
+ exit(-1);
+ }
+}
+
int elf_add_reloc_to_insn(struct elf *elf, struct section *sec,
unsigned long offset, unsigned int type,
struct section *insn_sec, unsigned long insn_off)
diff --git a/tools/objtool/include/objtool/elf.h
b/tools/objtool/include/objtool/elf.h
index adebfbc2b518..c43e23c0b3c8 100644
--- a/tools/objtool/include/objtool/elf.h
+++ b/tools/objtool/include/objtool/elf.h
@@ -144,6 +144,7 @@ static inline bool has_multiple_files(struct elf *elf)
struct elf *elf_open_read(const char *name, int flags);
struct section *elf_create_section(struct elf *elf, const char *name, unsigned
int sh_flags, size_t entsize, int nr);
+int elf_reloc_type_long(struct elf *elf);
int elf_add_reloc(struct elf *elf, struct section *sec, unsigned long offset,
unsigned int
[RFC PATCH 3/4] objtool/powerpc: Enable objtool to be built on ppc
This patch adds [stub] implementations for required
functions, inorder to enable objtool build on powerpc.
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
tools/objtool/arch/powerpc/Build | 2 +
tools/objtool/arch/powerpc/decode.c | 73 +++
.../arch/powerpc/include/arch/cfi_regs.h | 11 +++
tools/objtool/arch/powerpc/include/arch/elf.h | 8 ++
.../arch/powerpc/include/arch/endianness.h| 9 +++
.../arch/powerpc/include/arch/special.h | 21 ++
tools/objtool/arch/powerpc/special.c | 19 +
8 files changed, 144 insertions(+)
create mode 100644 tools/objtool/arch/powerpc/Build
create mode 100644 tools/objtool/arch/powerpc/decode.c
create mode 100644 tools/objtool/arch/powerpc/include/arch/cfi_regs.h
create mode 100644 tools/objtool/arch/powerpc/include/arch/elf.h
create mode 100644 tools/objtool/arch/powerpc/include/arch/endianness.h
create mode 100644 tools/objtool/arch/powerpc/include/arch/special.h
create mode 100644 tools/objtool/arch/powerpc/special.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 174edabb74fa..732a3f91ee5e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -232,6 +232,7 @@ config PPC
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 &&
PPC_BOOK3S)
select HAVE_OPTPROBES
+ select HAVE_OBJTOOL if PPC64
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
select HAVE_PERF_REGS
diff --git a/tools/objtool/arch/powerpc/Build b/tools/objtool/arch/powerpc/Build
new file mode 100644
index ..d24d5636a5b8
--- /dev/null
+++ b/tools/objtool/arch/powerpc/Build
@@ -0,0 +1,2 @@
+objtool-y += decode.o
+objtool-y += special.o
diff --git a/tools/objtool/arch/powerpc/decode.c
b/tools/objtool/arch/powerpc/decode.c
new file mode 100644
index ..e3b77a6ce357
--- /dev/null
+++ b/tools/objtool/arch/powerpc/decode.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+unsigned long arch_dest_reloc_offset(int addend)
+{
+ return addend;
+}
+
+bool arch_callee_saved_reg(unsigned char reg)
+{
+ return false;
+}
+
+int arch_decode_hint_reg(u8 sp_reg, int *base)
+{
+ return 0;
+}
+
+const char *arch_nop_insn(int len)
+{
+ return NULL;
+}
+
+const char *arch_ret_insn(int len)
+{
+ return NULL;
+}
+
+int arch_decode_instruction(struct objtool_file *file, const struct section
*sec,
+ unsigned long offset, unsigned int maxlen,
+ unsigned int *len, enum insn_type *type,
+ unsigned long *immediate,
+ struct list_head *ops_list)
+{
+ u32 insn;
+
+ *immediate = 0;
+ memcpy(, sec->data->d_buf+offset, 4);
+ *len = 4;
+ *type = INSN_OTHER;
+
+ return 0;
+}
+
+unsigned long arch_jump_destination(struct instruction *insn)
+{
+ return insn->offset + insn->immediate;
+}
+
+void arch_initial_func_cfi_state(struct cfi_init_state *state)
+{
+ int i;
+
+ for (i = 0; i < CFI_NUM_REGS; i++) {
+ state->regs[i].base = CFI_UNDEFINED;
+ state->regs[i].offset = 0;
+ }
+
+ /* initial CFA (call frame address) */
+ state->cfa.base = CFI_SP;
+ state->cfa.offset = 0;
+
+ /* initial LR (return address) */
+ state->regs[CFI_RA].base = CFI_CFA;
+ state->regs[CFI_RA].offset = 0;
+}
diff --git a/tools/objtool/arch/powerpc/include/arch/cfi_regs.h
b/tools/objtool/arch/powerpc/include/arch/cfi_regs.h
new file mode 100644
index ..59638ebeafc8
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/cfi_regs.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _OBJTOOL_CFI_REGS_H
+#define _OBJTOOL_CFI_REGS_H
+
+#define CFI_BP 1
+#define CFI_SP CFI_BP
+#define CFI_RA 32
+#define CFI_NUM_REGS 33
+
+#endif
diff --git a/tools/objtool/arch/powerpc/include/arch/elf.h
b/tools/objtool/arch/powerpc/include/arch/elf.h
new file mode 100644
index ..3c8ebb7d2a6b
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/elf.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef _OBJTOOL_ARCH_ELF
+#define _OBJTOOL_ARCH_ELF
+
+#define R_NONE R_PPC_NONE
+
+#endif /* _OBJTOOL_ARCH_ELF */
diff --git a/tools/objtool/arch/powerpc/include/arch/endianness.h
b/tools/objtool/arch/powerpc/include/arch/endianness.h
new file mode 100644
index ..7c362527da20
--- /dev/null
+++ b/tools/objtool/arch/powerpc/include/arch/endianness.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _ARCH_ENDIANNESS_H
+#define _ARCH_ENDIANNESS_H
+
+#include
+
+#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN
+
+#endif /*
[RFC PATCH 0/4] objtool: Enable and implement --mcount option on powerpc
These patches are rebased on top of objtool/core branch of the tip tree, and work only on ppc64le for now. Note: With this patch set, there are still some warnings seen with ppc64le kernel build. Sathvika Vasireddy (4): objtool: Add --mnop as an option to --mcount objtool: Enable objtool to run only on files with ftrace enabled objtool/powerpc: Enable objtool to be built on ppc objtool/powerpc: Add --mcount specific implementation Makefile | 4 +- arch/powerpc/Kconfig | 2 + arch/x86/Kconfig | 1 + scripts/Makefile.build| 5 +- tools/objtool/arch/powerpc/Build | 2 + tools/objtool/arch/powerpc/decode.c | 87 +++ .../arch/powerpc/include/arch/cfi_regs.h | 11 +++ tools/objtool/arch/powerpc/include/arch/elf.h | 8 ++ .../arch/powerpc/include/arch/endianness.h| 9 ++ .../arch/powerpc/include/arch/special.h | 21 + tools/objtool/arch/powerpc/special.c | 19 tools/objtool/builtin-check.c | 14 +++ tools/objtool/check.c | 31 --- tools/objtool/elf.c | 13 +++ tools/objtool/include/objtool/builtin.h | 1 + tools/objtool/include/objtool/elf.h | 1 + 16 files changed, 212 insertions(+), 17 deletions(-) create mode 100644 tools/objtool/arch/powerpc/Build create mode 100644 tools/objtool/arch/powerpc/decode.c create mode 100644 tools/objtool/arch/powerpc/include/arch/cfi_regs.h create mode 100644 tools/objtool/arch/powerpc/include/arch/elf.h create mode 100644 tools/objtool/arch/powerpc/include/arch/endianness.h create mode 100644 tools/objtool/arch/powerpc/include/arch/special.h create mode 100644 tools/objtool/arch/powerpc/special.c -- 2.25.1
[RFC PATCH 1/4] objtool: Add --mnop as an option to --mcount
Architectures can select HAVE_NOP_MCOUNT if they choose
to nop out mcount call sites. If that config option is
selected, then --mnop is passed as an option to objtool,
along with --mcount.
Also, make sure that --mnop can be passed as an option
to objtool only when --mcount is passed.
Signed-off-by: Sathvika Vasireddy
---
Makefile| 4 +++-
arch/x86/Kconfig| 1 +
scripts/Makefile.build | 1 +
tools/objtool/builtin-check.c | 14 ++
tools/objtool/check.c | 19 ++-
tools/objtool/include/objtool/builtin.h | 1 +
6 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 250707647359..acaf88e3c694 100644
--- a/Makefile
+++ b/Makefile
@@ -851,7 +851,9 @@ ifdef CONFIG_FTRACE_MCOUNT_USE_CC
endif
endif
ifdef CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
- CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT
+ ifdef CONFIG_HAVE_NOP_MCOUNT
+CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT
+ endif
endif
ifdef CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT
ifdef CONFIG_HAVE_C_RECORDMCOUNT
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1847d6e974a1..4a41bfb644f0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -189,6 +189,7 @@ config X86
select HAVE_CONTEXT_TRACKING_OFFSTACK if HAVE_CONTEXT_TRACKING
select HAVE_C_RECORDMCOUNT
select HAVE_OBJTOOL_MCOUNT if HAVE_OBJTOOL
+ select HAVE_NOP_MCOUNT if HAVE_OBJTOOL_MCOUNT
select HAVE_BUILDTIME_MCOUNT_SORT
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index ac8167227bc0..2e0c3f9c1459 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -231,6 +231,7 @@ objtool_args =
\
$(if $(CONFIG_HAVE_NOINSTR_HACK), --hacks=noinstr) \
$(if $(CONFIG_X86_KERNEL_IBT), --ibt) \
$(if $(CONFIG_FTRACE_MCOUNT_USE_OBJTOOL), --mcount) \
+ $(if $(CONFIG_HAVE_NOP_MCOUNT), --mnop) \
$(if $(CONFIG_UNWINDER_ORC), --orc) \
$(if $(CONFIG_RETPOLINE), --retpoline) \
$(if $(CONFIG_SLS), --sls) \
diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
index f4c3a5091737..b05e2108c0c3 100644
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -80,6 +80,7 @@ const struct option check_options[] = {
OPT_BOOLEAN(0, "dry-run", , "don't write modifications"),
OPT_BOOLEAN(0, "link", , "object is a linked object"),
OPT_BOOLEAN(0, "module", , "object is part of a kernel
module"),
+ OPT_BOOLEAN(0, "mnop", , "nop out mcount call sites"),
OPT_BOOLEAN(0, "no-unreachable", _unreachable, "skip
'unreachable instruction' warnings"),
OPT_BOOLEAN(0, "sec-address", _address, "print section
addresses in warnings"),
OPT_BOOLEAN(0, "stats", , "print statistics"),
@@ -142,6 +143,16 @@ static bool opts_valid(void)
return false;
}
+static bool mnop_opts_valid(void)
+{
+ if (opts.mnop && !opts.mcount) {
+ ERROR("--mnop requires --mcount");
+ return false;
+ }
+
+ return true;
+}
+
static bool link_opts_valid(struct objtool_file *file)
{
if (opts.link)
@@ -185,6 +196,9 @@ int objtool_run(int argc, const char **argv)
if (!file)
return 1;
+ if (!mnop_opts_valid())
+ return 1;
+
if (!link_opts_valid(file))
return 1;
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 190b2f6e360a..056302d58e23 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1175,17 +1175,18 @@ static void annotate_call_site(struct objtool_file
*file,
if (opts.mcount && sym->fentry) {
if (sibling)
WARN_FUNC("Tail call to __fentry__ !?!?", insn->sec,
insn->offset);
+ if (opts.mnop) {
+ if (reloc) {
+ reloc->type = R_NONE;
+ elf_write_reloc(file->elf, reloc);
+ }
- if (reloc) {
- reloc->type = R_NONE;
- elf_write_reloc(file->elf, reloc);
- }
-
- elf_write_insn(file->elf, insn->sec,
- insn->offset, insn->len,
- arch_nop_insn(insn->len));
+ elf_write_insn(file->elf, insn->sec,
+ insn->offset, insn->len,
+ arch_nop_insn(insn->len));
- insn->type = INSN_NOP;
+ insn->type =
[RFC PATCH 2/4] objtool: Enable objtool to run only on files with ftrace enabled
This patch makes sure objtool runs only on the object files that have ftrace enabled, instead of running on all the object files. Signed-off-by: Naveen N. Rao Signed-off-by: Sathvika Vasireddy --- scripts/Makefile.build | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 2e0c3f9c1459..06ceffd92921 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -258,8 +258,8 @@ else # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file -$(obj)/%.o: objtool-enabled = $(if $(filter-out y%, \ - $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y) +$(obj)/%.o: objtool-enabled = $(and $(if $(filter-out y%, $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y), \ +$(if $(findstring $(strip $(CC_FLAGS_FTRACE)),$(_c_flags)),y),y) endif -- 2.25.1
[PATCH 5.17 132/158] perf test bpf: Skip test if clang is not present
From: Athira Rajeev
[ Upstream commit 8994e97be3eb3c3a7b59d6223018ffab8c272e2d ]
Perf BPF filter test fails in environment where "clang" is not
installed.
Test failure logs:
<<>>
42: BPF filter:
42.1: Basic BPF filtering : Skip
42.2: BPF pinning : FAILED!
42.3: BPF prologue generation : FAILED!
<<>>
Enabling verbose option provided debug logs which says clang/llvm needs
to be installed. Snippet of verbose logs:
<<>>
42.2: BPF pinning :
--- start ---
test child forked, pid 61423
ERROR: unable to find clang.
Hint: Try to install latest clang/llvm to support BPF.
Check your $PATH
<>
Failed to compile test case: 'Basic BPF llvm compile'
Unable to get BPF object, fix kbuild first
test child finished with -1
end
BPF filter subtest 2: FAILED!
<<>>
Here subtests, "BPF pinning" and "BPF prologue generation" failed and
logs shows clang/llvm is needed. After installing clang, testcase
passes.
Reason on why subtest failure happens though logs has proper debug
information:
Main function __test__bpf calls test_llvm__fetch_bpf_obj by
passing 4th argument as true ( 4th arguments maps to parameter
"force" in test_llvm__fetch_bpf_obj ). But this will cause
test_llvm__fetch_bpf_obj to skip the check for clang/llvm.
Snippet of code part which checks for clang based on
parameter "force" in test_llvm__fetch_bpf_obj:
<<>>
if (!force && (!llvm_param.user_set_param &&
<<>>
Since force is set to "false", test won't get skipped and fails to
compile test case. The BPF code compilation needs clang, So pass the
fourth argument as "false" and also skip the test if reason for return
is "TEST_SKIP"
After the patch:
<<>>
42: BPF filter:
42.1: Basic BPF filtering : Skip
42.2: BPF pinning : Skip
42.3: BPF prologue generation : Skip
<<>>
Fixes: ba1fae431e74bb42 ("perf test: Add 'perf test BPF'")
Reviewed-by: Kajol Jain
Signed-off-by: Athira Jajeev
Acked-by: Ian Rogers
Cc: Disha Goel
Cc: Jiri Olsa
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nageswara R Sastry
Cc: Wang Nan
Link:
https://lore.kernel.org/r/2022055438.84032-1-atraj...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/tests/bpf.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 573490530194..592ab02d5ba3 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -222,11 +222,11 @@ static int __test__bpf(int idx)
ret = test_llvm__fetch_bpf_obj(_buf, _buf_sz,
bpf_testcase_table[idx].prog_id,
- true, NULL);
+ false, NULL);
if (ret != TEST_OK || !obj_buf || !obj_buf_sz) {
pr_debug("Unable to get BPF object, %s\n",
bpf_testcase_table[idx].msg_compile_fail);
- if (idx == 0)
+ if ((idx == 0) || (ret == TEST_SKIP))
return TEST_SKIP;
else
return TEST_FAIL;
@@ -370,9 +370,11 @@ static int test__bpf_prologue_test(struct test_suite *test
__maybe_unused,
static struct test_case bpf_tests[] = {
#ifdef HAVE_LIBBPF_SUPPORT
TEST_CASE("Basic BPF filtering", basic_bpf_test),
- TEST_CASE("BPF pinning", bpf_pinning),
+ TEST_CASE_REASON("BPF pinning", bpf_pinning,
+ "clang isn't installed or environment missing BPF
support"),
#ifdef HAVE_BPF_PROLOGUE
- TEST_CASE("BPF prologue generation", bpf_prologue_test),
+ TEST_CASE_REASON("BPF prologue generation", bpf_prologue_test,
+ "clang isn't installed or environment missing BPF
support"),
#else
TEST_CASE_REASON("BPF prologue generation", bpf_prologue_test, "not
compiled in"),
#endif
--
2.35.1
[PATCH 5.17 129/158] perf test: Fix "all PMU test" to skip hv_24x7/hv_gpci tests on powerpc
From: Athira Rajeev
[ Upstream commit 451ed8058c69a3fee29fa9e2967a4e22a221fe75 ]
"perf all PMU test" picks the input events from "perf list --raw-dump
pmu" list and runs "perf stat -e" for each of the event in the list. In
case of powerpc, the PowerVM environment supports events from hv_24x7
and hv_gpci PMU which is of example format like below:
- hv_24x7/CPM_ADJUNCT_INST,domain=?,core=?/
- hv_gpci/event,partition_id=?/
The value for "?" needs to be filled in depending on system and
respective event. CPM_ADJUNCT_INST needs have core value and domain
value. hv_gpci event needs partition_id. Similarly, there are other
events for hv_24x7 and hv_gpci having "?" in event format. Hence skip
these events on powerpc platform since values like partition_id, domain
is specific to system and event.
Fixes: 3d5ac9effcc640d5 ("perf test: Workload test of all PMUs")
Signed-off-by: Athira Jajeev
Acked-by: Ian Rogers
Cc: Disha Goel
Cc: Jiri Olsa
Cc: Kajol Jain
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nageswara R Sastry
Link:
https://lore.kernel.org/r/20220520101236.17249-1-atraj...@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Sasha Levin
---
tools/perf/tests/shell/stat_all_pmu.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/perf/tests/shell/stat_all_pmu.sh
b/tools/perf/tests/shell/stat_all_pmu.sh
index b30dba455f36..9c9ef33e0b3c 100755
--- a/tools/perf/tests/shell/stat_all_pmu.sh
+++ b/tools/perf/tests/shell/stat_all_pmu.sh
@@ -5,6 +5,16 @@
set -e
for p in $(perf list --raw-dump pmu); do
+ # In powerpc, skip the events for hv_24x7 and hv_gpci.
+ # These events needs input values to be filled in for
+ # core, chip, partition id based on system.
+ # Example: hv_24x7/CPM_ADJUNCT_INST,domain=?,core=?/
+ # hv_gpci/event,partition_id=?/
+ # Hence skip these events for ppc.
+ if echo "$p" |grep -Eq 'hv_24x7|hv_gpci' ; then
+echo "Skipping: Event '$p' in powerpc"
+continue
+ fi
echo "Testing $p"
result=$(perf stat -e "$p" true 2>&1)
if ! echo "$result" | grep -q "$p" && ! echo "$result" | grep -q "" ; then
--
2.35.1
Re: [PATCH v10 10/13] powerpc/mm: Move get_unmapped_area functions to slice.c
On 23/05/2022, 17:18:10, Christophe Leroy wrote:
>
>
> Le 23/05/2022 à 14:27, Laurent Dufour a écrit :
>> On 09/04/2022, 19:17:34, Christophe Leroy wrote:
>>> hugetlb_get_unmapped_area() is now identical to the
>>> generic version if only RADIX is enabled, so move it
>>> to slice.c and let it fallback on the generic one
>>> when HASH MMU is not compiled in.
>>>
>>> Do the same with arch_get_unmapped_area() and
>>> arch_get_unmapped_area_topdown().
>>
>> This breaks the build when CONFIG_PPC_64S_HASH_MMU is not set.
>>
>> The root cause is that arch/powerpc/mm/book3s64/slice.c is not built if
>> !CONFIG_PPC_64S_HASH_MMU.
>> The commit f693d38d9468 (powerpc/mm: Remove CONFIG_PPC_MM_SLICES,
>> 2022-04-09) builds slice.c only if CONFIG_PPC_64S_HASH_MMU.
>
> I think the root cause is slice.h is being included allthough
> !CONFIG_PPC_64S_HASH_MMU, which leads to HAVE_ARCH_UNMAPPED_AREA and
> HAVE_ARCH_UNMAPPED_AREA_TOPDOWN being defined while they shouldn't
>
> Wondering why I didn't see that before.
>
> slice.h gets included via asm/book3s/64/mmu-hash.h
>
> I was able to build microwatt_defconfig with the following changes:
That works for me too.
>
> diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
> b/arch/powerpc/include/asm/book3s/64/slice.h
> index b8eb4ad271b9..5fbe18544cbd 100644
> --- a/arch/powerpc/include/asm/book3s/64/slice.h
> +++ b/arch/powerpc/include/asm/book3s/64/slice.h
> @@ -4,11 +4,13 @@
>
> #ifndef __ASSEMBLY__
>
> +#ifdef CONFIG_PPC_64S_HASH_MMU
> #ifdef CONFIG_HUGETLB_PAGE
> #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
> #endif
> #define HAVE_ARCH_UNMAPPED_AREA
> #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
> +#endif
>
> #define SLICE_LOW_SHIFT 28
> #define SLICE_LOW_TOP (0x1ul)
> diff --git a/arch/powerpc/sysdev/xics/ics-native.c
> b/arch/powerpc/sysdev/xics/ics-native.c
> index e33b77da861e..112c8a1e8159 100644
> --- a/arch/powerpc/sysdev/xics/ics-native.c
> +++ b/arch/powerpc/sysdev/xics/ics-native.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
>
>
>>
>> I'm wondering if these functions have to be moved in slice.c
>>
>> Attached is the config file I used.
>>
>>> Signed-off-by: Christophe Leroy
>>> ---
>>> arch/powerpc/include/asm/book3s/64/mmu.h | 6
>>> arch/powerpc/include/asm/book3s/64/slice.h | 6
>>> arch/powerpc/mm/book3s64/slice.c | 42 ++
>>> arch/powerpc/mm/hugetlbpage.c | 21 ---
>>> arch/powerpc/mm/mmap.c | 36 ---
>>> 5 files changed, 48 insertions(+), 63 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
>>> b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> index 006cbec70ffe..570a4960cf17 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> @@ -4,12 +4,6 @@
>>>
>>> #include
>>>
>>> -#ifdef CONFIG_HUGETLB_PAGE
>>> -#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>>> -#endif
>>> -#define HAVE_ARCH_UNMAPPED_AREA
>>> -#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>>> -
>>> #ifndef __ASSEMBLY__
>>> /*
>>>* Page size definition
>>> diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
>>> b/arch/powerpc/include/asm/book3s/64/slice.h
>>> index 5b0f7105bc8b..b8eb4ad271b9 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/slice.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/slice.h
>>> @@ -4,6 +4,12 @@
>>>
>>> #ifndef __ASSEMBLY__
>>>
>>> +#ifdef CONFIG_HUGETLB_PAGE
>>> +#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>>> +#endif
>>> +#define HAVE_ARCH_UNMAPPED_AREA
>>> +#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>>> +
>>> #define SLICE_LOW_SHIFT 28
>>> #define SLICE_LOW_TOP (0x1ul)
>>> #define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT)
>>> diff --git a/arch/powerpc/mm/book3s64/slice.c
>>> b/arch/powerpc/mm/book3s64/slice.c
>>> index e4382713746d..03681042b807 100644
>>> --- a/arch/powerpc/mm/book3s64/slice.c
>>> +++ b/arch/powerpc/mm/book3s64/slice.c
>>> @@ -639,6 +639,32 @@ unsigned long slice_get_unmapped_area(unsigned long
>>> addr, unsigned long len,
>>> }
>>> EXPORT_SYMBOL_GPL(slice_get_unmapped_area);
>>>
>>> +unsigned long arch_get_unmapped_area(struct file *filp,
>>> +unsigned long addr,
>>> +unsigned long len,
>>> +unsigned long pgoff,
>>> +unsigned long flags)
>>> +{
>>> + if (radix_enabled())
>>> + return generic_get_unmapped_area(filp, addr, len, pgoff, flags);
>>> +
>>> + return slice_get_unmapped_area(addr, len, flags,
>>> +
>>> mm_ctx_user_psize(>mm->context), 0);
>>> +}
>>> +
>>> +unsigned long arch_get_unmapped_area_topdown(struct file *filp,
>>> +const unsigned
[PATCH v2] powerpc/64s: Don't read H_BLOCK_REMOVE characteristics in radix mode
There is no need to read the H_BLOCK_REMOVE characteristics when running in
Radix mode because this hcall is never called.
Furthermore since the commit 387e220a2e5e ("powerpc/64s: Move hash MMU
support code under CONFIG_PPC_64S_HASH_MMU") define
pseries_lpar_read_hblkrm_characteristics as un empty function if
CONFIG_PPC_64S_HASH_MMU is not set, the #ifdef block can be removed.
Cc: Nicholas Piggin
Cc: Christophe Leroy
Signed-off-by: Laurent Dufour
---
arch/powerpc/platforms/pseries/setup.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index c9fcc30a0365..6d7d31d8099d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -802,9 +802,8 @@ static void __init pSeries_setup_arch(void)
fwnmi_init();
pseries_setup_security_mitigations();
-#ifdef CONFIG_PPC_64S_HASH_MMU
- pseries_lpar_read_hblkrm_characteristics();
-#endif
+ if (!radix_enabled())
+ pseries_lpar_read_hblkrm_characteristics();
/* By default, only probe PCI (can be overridden by rtas_pci) */
pci_add_flags(PCI_PROBE_ONLY);
--
2.36.1
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
On 5/23/22 08:18, Guo Ren wrote: I tested Palmer's branch, it's okay: 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a bogus mmu-type on a no MMU kernel I also tested linux-next, it's okay: rv64_rootfs: # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # That is is ok with one setup doesn't mean it is ok with all setups. It is not ok with my root file system (from https://github.com/groeck/linux-build-test/tree/master/rootfs/riscv64), with qemu v6.2. # # # ls /lib ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so libatomic.so libc.so.1modules My root file system uses musl. Guenter rv32_rootfs: buildroot login: root # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # ls /lib ld-linux-riscv32-ilp32d.so.1 libm.so.6 libanl.so.1 libnss_dns.so.2 libatomic.so libnss_files.so.2 libatomic.so.1libpthread.so.0 libatomic.so.1.2.0libresolv.so.2 libc.so.6 librt.so.1 libcrypt.so.1 libthread_db.so.1 libdl.so.2libutil.so.1 libgcc_s.so modules libgcc_s.so.1 Here is my qemu version: commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> riscv-to-apply.next, alistair/riscv-to-apply.next) Author: Tsukasa OI Date: Sun May 15 11:56:11 2022 +0900 target/riscv: Move/refactor ISA extension checks We should separate "check" and "configure" steps as possible. This commit separates both steps except vector/Zfinx-related checks. Signed-off-by: Tsukasa OI Reviewed-by: Alistair Francis Message-Id: Signed-off-by: Alistair Francis On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: From: Guo Ren Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on 64bit S-mode) support. - Setup kconfig & dummy functions for compiling. - Implement compat_start_thread by the way. Signed-off-by: Guo Ren Signed-off-by: Guo Ren Reviewed-by: Arnd Bergmann Tested-by: Heiko Stuebner Cc: Palmer Dabbelt With this patch in linux-next, all my riscv64 emulations crash. [ 11.600082] Run /sbin/init as init process [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in libc.so[ff8ad39000+a4000] [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.629462] Hardware name: riscv-virtio,qemu (DT) [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : 00ffc58199f0 [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : 00ff8ade0cc0 [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : 00ffc5819a00 [ 11.629622] a2 : 0001 a3 : 001e a4 : 00ffc5819b00 [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : 00ff8ade0728 [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : 00ffc5819e40 [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: [ 11.629678] s11: t3 : 0002 t4 : 0001 [ 11.629688] t5 : 0002 t6 : [ 11.629699] status: 4020 badaddr: cause: 000d [ 11.633421] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 #1 [ 11.633784] Hardware name: riscv-virtio,qemu (DT) [ 11.633881] Call Trace: [ 11.633960] [] dump_backtrace+0x1c/0x24 [ 11.634162] [] show_stack+0x2c/0x38 [ 11.634274] [] dump_stack_lvl+0x60/0x8e [ 11.634386] [] dump_stack+0x14/0x1c [ 11.634491] [] panic+0x116/0x2e2 [ 11.634596] [] do_exit+0x7ce/0x7d4 [ 11.634707] [] do_group_exit+0x24/0x7c [ 11.634817] [] get_signal+0x7ee/0x830 [ 11.634924] [] do_notify_resume+0x6c/0x41c [ 11.635037] [] ret_from_exception+0x0/0x10 Guenter --- # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific files for 20220520 # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 git bisect start 'HEAD' 'v5.18-rc7' # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux git bisect bad 7db97132097c5973ff77466d0ee681650af653de # good: [2b7d17d4b7c1ff4
Re: [PATCH] powerpc/64s: Don't read H_BLOCK_REMOVE characteristics in radix mode
On 20/05/2022, 18:15:39, Christophe Leroy wrote: > > > Le 20/05/2022 à 17:57, Laurent Dufour a écrit : >> There is no need to read the H_BLOCK_REMOVE characteristics when running in >> Radix mode because this hcall is never called. >> >> Signed-off-by: Laurent Dufour >> --- >> arch/powerpc/platforms/pseries/setup.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/platforms/pseries/setup.c >> b/arch/powerpc/platforms/pseries/setup.c >> index c9fcc30a0365..654d2b999c25 100644 >> --- a/arch/powerpc/platforms/pseries/setup.c >> +++ b/arch/powerpc/platforms/pseries/setup.c >> @@ -803,7 +803,8 @@ static void __init pSeries_setup_arch(void) >> >> pseries_setup_security_mitigations(); >> #ifdef CONFIG_PPC_64S_HASH_MMU >> -pseries_lpar_read_hblkrm_characteristics(); >> +if (!radix_enabled()) >> +pseries_lpar_read_hblkrm_characteristics(); >> #endif > > As far as I can see the function always exists so the #ifdef can be removed. You're right, I'll do that in the v2 >> >> /* By default, only probe PCI (can be overridden by rtas_pci) */
Re: [PATCH V9 20/20] riscv: compat: Add COMPAT Kbuild skeletal support
I tested Palmer's branch, it's okay: 8810d7feee5a (HEAD -> for-next, palmer/for-next) riscv: Don't output a bogus mmu-type on a no MMU kernel I also tested linux-next, it's okay: rv64_rootfs: # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # # # # ls /lib ld-uClibc-1.0.39.so libatomic.so.1 libgcc_s.so ld-uClibc.so.0 libatomic.so.1.2.0 libgcc_s.so.1 ld-uClibc.so.1 libc.so.0libuClibc-1.0.39.so libatomic.so libc.so.1modules rv32_rootfs: buildroot login: root # uname -a Linux buildroot 5.18.0-next-20220523 #7 SMP Mon May 23 11:15:17 EDT 2022 riscv64 GNU/Linux # ls /lib ld-linux-riscv32-ilp32d.so.1 libm.so.6 libanl.so.1 libnss_dns.so.2 libatomic.so libnss_files.so.2 libatomic.so.1libpthread.so.0 libatomic.so.1.2.0libresolv.so.2 libc.so.6 librt.so.1 libcrypt.so.1 libthread_db.so.1 libdl.so.2libutil.so.1 libgcc_s.so modules libgcc_s.so.1 Here is my qemu version: commit 19f13a92cef8405052e0f73d5289f9e15474dad3 (HEAD -> riscv-to-apply.next, alistair/riscv-to-apply.next) Author: Tsukasa OI Date: Sun May 15 11:56:11 2022 +0900 target/riscv: Move/refactor ISA extension checks We should separate "check" and "configure" steps as possible. This commit separates both steps except vector/Zfinx-related checks. Signed-off-by: Tsukasa OI Reviewed-by: Alistair Francis Message-Id: Signed-off-by: Alistair Francis On Mon, May 23, 2022 at 1:45 PM Guenter Roeck wrote: > > On Tue, Mar 22, 2022 at 10:40:03PM +0800, guo...@kernel.org wrote: > > From: Guo Ren > > > > Adds initial skeletal COMPAT Kbuild (Running 32bit U-mode on > > 64bit S-mode) support. > > - Setup kconfig & dummy functions for compiling. > > - Implement compat_start_thread by the way. > > > > Signed-off-by: Guo Ren > > Signed-off-by: Guo Ren > > Reviewed-by: Arnd Bergmann > > Tested-by: Heiko Stuebner > > Cc: Palmer Dabbelt > > With this patch in linux-next, all my riscv64 emulations crash. > > [ 11.600082] Run /sbin/init as init process > [ 11.628561] init[1]: unhandled signal 11 code 0x1 at 0x in > libc.so[ff8ad39000+a4000] > [ 11.629398] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.629462] Hardware name: riscv-virtio,qemu (DT) > [ 11.629546] epc : 00ff8ada1100 ra : 00ff8ada13c8 sp : > 00ffc58199f0 > [ 11.629586] gp : 00ff8ad39000 tp : 00ff8ade0998 t0 : > > [ 11.629598] t1 : 00ffc5819fd0 t2 : s0 : > 00ff8ade0cc0 > [ 11.629610] s1 : 00ff8ade0cc0 a0 : a1 : > 00ffc5819a00 > [ 11.629622] a2 : 0001 a3 : 001e a4 : > 00ffc5819b00 > [ 11.629634] a5 : 00ffc5819b00 a6 : a7 : > > [ 11.629645] s2 : 00ff8ade0ac8 s3 : 00ff8ade0ec8 s4 : > 00ff8ade0728 > [ 11.629656] s5 : 00ff8ade0a90 s6 : s7 : > 00ffc5819e40 > [ 11.629667] s8 : 00ff8ade0ca0 s9 : 00ff8addba50 s10: > > [ 11.629678] s11: t3 : 0002 t4 : > 0001 > [ 11.629688] t5 : 0002 t6 : > [ 11.629699] status: 4020 badaddr: cause: > 000d > [ 11.633421] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b > [ 11.633664] CPU: 0 PID: 1 Comm: init Not tainted 5.18.0-rc7-next-20220520 > #1 > [ 11.633784] Hardware name: riscv-virtio,qemu (DT) > [ 11.633881] Call Trace: > [ 11.633960] [] dump_backtrace+0x1c/0x24 > [ 11.634162] [] show_stack+0x2c/0x38 > [ 11.634274] [] dump_stack_lvl+0x60/0x8e > [ 11.634386] [] dump_stack+0x14/0x1c > [ 11.634491] [] panic+0x116/0x2e2 > [ 11.634596] [] do_exit+0x7ce/0x7d4 > [ 11.634707] [] do_group_exit+0x24/0x7c > [ 11.634817] [] get_signal+0x7ee/0x830 > [ 11.634924] [] do_notify_resume+0x6c/0x41c > [ 11.635037] [] ret_from_exception+0x0/0x10 > > Guenter > > --- > # bad: [18ecd30af1a8402c162cca1bd58771c0e5be7815] Add linux-next specific > files for 20220520 > # good: [42226c989789d8da4af1de0c31070c96726d990c] Linux 5.18-rc7 > git bisect start 'HEAD' 'v5.18-rc7' > # bad: [f9b63740b666dd9887eb0282d21b5f65bb0cadd0] Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > git bisect bad f9b63740b666dd9887eb0282d21b5f65bb0cadd0 > # bad: [7db97132097c5973ff77466d0ee681650af653de] Merge branch 'for-next' of > git://g
Re: [PATCH v10 10/13] powerpc/mm: Move get_unmapped_area functions to slice.c
Le 23/05/2022 à 14:27, Laurent Dufour a écrit :
> On 09/04/2022, 19:17:34, Christophe Leroy wrote:
>> hugetlb_get_unmapped_area() is now identical to the
>> generic version if only RADIX is enabled, so move it
>> to slice.c and let it fallback on the generic one
>> when HASH MMU is not compiled in.
>>
>> Do the same with arch_get_unmapped_area() and
>> arch_get_unmapped_area_topdown().
>
> This breaks the build when CONFIG_PPC_64S_HASH_MMU is not set.
>
> The root cause is that arch/powerpc/mm/book3s64/slice.c is not built if
> !CONFIG_PPC_64S_HASH_MMU.
> The commit f693d38d9468 (powerpc/mm: Remove CONFIG_PPC_MM_SLICES,
> 2022-04-09) builds slice.c only if CONFIG_PPC_64S_HASH_MMU.
I think the root cause is slice.h is being included allthough
!CONFIG_PPC_64S_HASH_MMU, which leads to HAVE_ARCH_UNMAPPED_AREA and
HAVE_ARCH_UNMAPPED_AREA_TOPDOWN being defined while they shouldn't
Wondering why I didn't see that before.
slice.h gets included via asm/book3s/64/mmu-hash.h
I was able to build microwatt_defconfig with the following changes:
diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
b/arch/powerpc/include/asm/book3s/64/slice.h
index b8eb4ad271b9..5fbe18544cbd 100644
--- a/arch/powerpc/include/asm/book3s/64/slice.h
+++ b/arch/powerpc/include/asm/book3s/64/slice.h
@@ -4,11 +4,13 @@
#ifndef __ASSEMBLY__
+#ifdef CONFIG_PPC_64S_HASH_MMU
#ifdef CONFIG_HUGETLB_PAGE
#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
#endif
#define HAVE_ARCH_UNMAPPED_AREA
#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
+#endif
#define SLICE_LOW_SHIFT 28
#define SLICE_LOW_TOP (0x1ul)
diff --git a/arch/powerpc/sysdev/xics/ics-native.c
b/arch/powerpc/sysdev/xics/ics-native.c
index e33b77da861e..112c8a1e8159 100644
--- a/arch/powerpc/sysdev/xics/ics-native.c
+++ b/arch/powerpc/sysdev/xics/ics-native.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
>
> I'm wondering if these functions have to be moved in slice.c
>
> Attached is the config file I used.
>
>> Signed-off-by: Christophe Leroy
>> ---
>> arch/powerpc/include/asm/book3s/64/mmu.h | 6
>> arch/powerpc/include/asm/book3s/64/slice.h | 6
>> arch/powerpc/mm/book3s64/slice.c | 42 ++
>> arch/powerpc/mm/hugetlbpage.c | 21 ---
>> arch/powerpc/mm/mmap.c | 36 ---
>> 5 files changed, 48 insertions(+), 63 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
>> b/arch/powerpc/include/asm/book3s/64/mmu.h
>> index 006cbec70ffe..570a4960cf17 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>> @@ -4,12 +4,6 @@
>>
>> #include
>>
>> -#ifdef CONFIG_HUGETLB_PAGE
>> -#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>> -#endif
>> -#define HAVE_ARCH_UNMAPPED_AREA
>> -#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>> -
>> #ifndef __ASSEMBLY__
>> /*
>>* Page size definition
>> diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
>> b/arch/powerpc/include/asm/book3s/64/slice.h
>> index 5b0f7105bc8b..b8eb4ad271b9 100644
>> --- a/arch/powerpc/include/asm/book3s/64/slice.h
>> +++ b/arch/powerpc/include/asm/book3s/64/slice.h
>> @@ -4,6 +4,12 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#ifdef CONFIG_HUGETLB_PAGE
>> +#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>> +#endif
>> +#define HAVE_ARCH_UNMAPPED_AREA
>> +#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>> +
>> #define SLICE_LOW_SHIFT28
>> #define SLICE_LOW_TOP (0x1ul)
>> #define SLICE_NUM_LOW (SLICE_LOW_TOP >> SLICE_LOW_SHIFT)
>> diff --git a/arch/powerpc/mm/book3s64/slice.c
>> b/arch/powerpc/mm/book3s64/slice.c
>> index e4382713746d..03681042b807 100644
>> --- a/arch/powerpc/mm/book3s64/slice.c
>> +++ b/arch/powerpc/mm/book3s64/slice.c
>> @@ -639,6 +639,32 @@ unsigned long slice_get_unmapped_area(unsigned long
>> addr, unsigned long len,
>> }
>> EXPORT_SYMBOL_GPL(slice_get_unmapped_area);
>>
>> +unsigned long arch_get_unmapped_area(struct file *filp,
>> + unsigned long addr,
>> + unsigned long len,
>> + unsigned long pgoff,
>> + unsigned long flags)
>> +{
>> +if (radix_enabled())
>> +return generic_get_unmapped_area(filp, addr, len, pgoff, flags);
>> +
>> +return slice_get_unmapped_area(addr, len, flags,
>> +
>> mm_ctx_user_psize(>mm->context), 0);
>> +}
>> +
>> +unsigned long arch_get_unmapped_area_topdown(struct file *filp,
>> + const unsigned long addr0,
>> + const unsigned long len,
>> + const unsigned long pgoff,
>> + const unsigned long flags)
>> +{
>> +if
Re: [RFC Linux patch] powerpc: add documentation for HWCAPs
On 5/20/22 7:11 PM, Nicholas Piggin wrote: Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am: On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote: +PPC_FEATURE2_TAR +VSX facility is available. Was manipulating the tar spr was once a privileged instruction, is this a hint userspace can use the related instructions? It can be disabled with facility control, and I guess there was some consideration for how it might be used, e.g., "system software" could use it for its own purpose then clear the bit for the application. In practice I don't really know what makes use of this or whether anything sanely can, it's marked reserved in the ABI. Would be interesting to know whether there is much benefit to use it in the compiler. The kernel could actually use it for something nifty if we were able to prevent userspace from accessing it entirely... It might be useful as a scratch register for indirect branches in some odd cases, such as golang's preemptive userspace threading. Though, it seems more trouble than its worth for a very limited benefit. + +PPC_FEATURE2_HAS_IEEE128 +IEEE 128 is available? What instructions/data? Maybe something like "IEEE 128 binary floating point instructions are supported. Individual instruction availability is dependent on the reported architecture version."? Right, I just didn't know what architectural class of instructions those are. Is it just VSX in general or are there some specific things we can name? I think ISA 3.1 buckets this into an OpenPOWER Linux Optional Feature for "Quad-precision floating-point (QFP)". I guess ISA 3.0 predates those categorizations. +PPC_FEATURE2_MMA +MMA facility is available. Maybe another note that specific instruction availability may depend on the reported architecture version? Yep. I wonder if it would help to note how these align (or don't) with the various OpenPOWER features.
[RFC PATCH] powerpc/numa: Return the first online node instead of 0
If early cpu to node mapping finds an invalid node id, return the first online node instead of node 0. On ppc, we can find node 0 not present. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/topology.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h index 36fcafb1fd6d..3f07231d33b3 100644 --- a/arch/powerpc/include/asm/topology.h +++ b/arch/powerpc/include/asm/topology.h @@ -60,7 +60,7 @@ static inline int early_cpu_to_node(int cpu) * Fall back to node 0 if nid is unset (it should be, except bugs). * This allows callers to safely do NODE_DATA(early_cpu_to_node(cpu)). */ - return (nid < 0) ? 0 : nid; + return (nid < 0) ? first_online_node : nid; } int of_drconf_to_nid_single(struct drmem_lmb *lmb); -- 2.36.1
[RFC PATCH] powerpc/numa: Return the first online node if device tree mapping returns a not online node
numa_setup_cpu can return nodes that are not online. But setup_node_data() only initialize NODE_DATA for only online numa nodes. Hence avoid returning nodes that are not online. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/numa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c index 3becb2588726..80d9be07552c 100644 --- a/arch/powerpc/mm/numa.c +++ b/arch/powerpc/mm/numa.c @@ -742,7 +742,7 @@ static int numa_setup_cpu(unsigned long lcpu) of_node_put(cpu); out_present: - if (nid < 0 || !node_possible(nid)) + if (nid < 0 || !node_online(nid)) nid = first_online_node; /* -- 2.36.1
Re: [PATCH net-next] eth: de4x5: remove support for Generic DECchip & DIGITAL EtherWORKS PCI/EISA
Hello: This patch was applied to netdev/net-next.git (master) by David S. Miller : On Wed, 18 May 2022 20:13:45 -0700 you wrote: > Looks like almost all changes to this driver had been tree-wide > refactoring since git era begun. There is one commit from Al > 15 years ago which could potentially be fixing a real bug. > > The driver is using virt_to_bus() and is a real magnet for pointless > cleanups. It seems unlikely to have real users. Let's try to shed > this maintenance burden. > > [...] Here is the summary with links: - [net-next] eth: de4x5: remove support for Generic DECchip & DIGITAL EtherWORKS PCI/EISA https://git.kernel.org/netdev/net-next/c/32c53420d2a0 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] powerpc/microwatt: Add mmu bits to device tree
On Fri, 20 May 2022 at 00:06, Nicholas Piggin wrote:
>
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from the
> > device tree. If they are not found, there is a fallback, but Microwatt
> > wasn't covered as has the unusual configuration of being both !HV and bare
> > metal.
> >
> > Set the values in the device tree to avoid having to add a special case.
> > The lpid value is the only one required, but add both for completeness.
> >
> > Fixes: 5402e239d09f ("powerpc/64s: Get LPID bit width from device tree")
> > Signed-off-by: Joel Stanley
>
> LGTM... does Microwatt actually need 12 lpid bits, or does it just need
> the LPID 0 partition table entry? I wonder if you set it to 1. That's
> a minor nit though.
0, 1, 4, 5, 6, 7 fails. 8, 9, 10, 11, 12 work.
I'll let someone else explain why that is!
Oh, it's because we use it like this:
arch/powerpc/include/asm/book3s/64/mmu.h:#define PATB_SIZE_SHIFT
(mmu_lpid_bits + 4)
and then
arch/powerpc/mm/book3s64/radix_pgtable.c:
set_ptcr_when_no_uv(__pa(partition_tb) |
arch/powerpc/mm/book3s64/radix_pgtable.c:
(PATB_SIZE_SHIFT - 12));
so anything less than 8 will result in a negative value there.
The ISA says (from Figure 22 in 3.1, or 21 in 3.0B):
Partition Table Size=2**(12+PATS), PATS<= 24.
>From this it's clear that 12 >= mmu_lpid_bits >= 24.
(except there's only 4 bits for PATS in the ISA, so really the maximum is 16?)
What's not clear to me is why we define PATB_SIZE_SHIFT as mmu_lpid_bits + 4.
Cheers,
Joel
>
> Acked-by: Nicholas Piggin
>
> > ---
> > arch/powerpc/boot/dts/microwatt.dts | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/microwatt.dts
> > b/arch/powerpc/boot/dts/microwatt.dts
> > index 65b270a90f94..b69db1d275cd 100644
> > --- a/arch/powerpc/boot/dts/microwatt.dts
> > +++ b/arch/powerpc/boot/dts/microwatt.dts
> > @@ -90,6 +90,8 @@ PowerPC,Microwatt@0 {
> > 64-bit;
> > d-cache-size = <0x1000>;
> > ibm,chip-id = <0>;
> > + ibm,mmu-lpid-bits = <12>;
> > + ibm,mmu-pid-bits = <20>;
> > };
> > };
> >
> > --
> > 2.35.1
> >
> >
Re: [PATCH] powerpc/microwatt: Add mmu bits to device tree
On Fri, 2022-05-20 at 10:06 +1000, Nicholas Piggin wrote:
> Excerpts from Joel Stanley's message of May 19, 2022 10:57 pm:
> > In commit 5402e239d09f ("powerpc/64s: Get LPID bit width from device
> > tree") the kernel tried to determine the pid and lpid bits from the
> > device tree. If they are not found, there is a fallback, but Microwatt
> > wasn't covered as has the unusual configuration of being both !HV and bare
> > metal.
> >
> > Set the values in the device tree to avoid having to add a special case.
> > The lpid value is the only one required, but add both for completeness.
> >
> > Fixes: 5402e239d09f ("powerpc/64s: Get LPID bit width from device tree")
> > Signed-off-by: Joel Stanley
>
> LGTM... does Microwatt actually need 12 lpid bits, or does it just need
> the LPID 0 partition table entry?
Microwatt just assumes LPID=0 as it doesn't actually have an LPID SPR. It just
uses the first entry in the partition table.
There are some details here:
https://github.com/antonblanchard/microwatt/commit/18120f153d138f733fa7e8a89c3456bb93683f96
> I wonder if you set it to 1. That's a minor nit though.
.. or even set it to 0.
Mikey
[powerpc] linux-next 20220520 boot failure (drc_pmem_query_stats)
While booting linux-next (5.18.0-rc7-next-20220520) on a Power10 LPAR configure with pmem following oops is seen. The LPAR fails to boot to login prompt. [ 10.948211] papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Permission denied while accessing performance stats [ 10.948536] Kernel attempted to write user page (1c) - exploit attempt? (uid: 0) [ 10.948539] BUG: Kernel NULL pointer dereference on write at 0x001c [ 10.948540] Faulting instruction address: 0xc00801b90844 [ 10.948542] Oops: Kernel access of bad area, sig: 11 [#1] [ 10.948563] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries [ 10.948568] Modules linked in: papr_scm(E+) libnvdimm(E) vmx_crypto(E) ext4(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc64_rocksoft(E) crc64(E) sg(E) ibmvscsi(E) scsi_transport_srp(E) ibmveth(E) fuse(E) [ 10.948587] CPU: 25 PID: 796 Comm: systemd-udevd Tainted: GE 5.18.0-rc7-next-20220520 #2 [ 10.948592] NIP: c00801b90844 LR: c00801b92794 CTR: c00801b907f8 [ 10.948595] REGS: c0003082b110 TRAP: 0300 Tainted: GE (5.18.0-rc7-next-20220520) [ 10.948600] MSR: 8280b033 CR: 44222822 XER: 0001 [ 10.948613] CFAR: c007c744 DAR: 001c DSISR: 4200 IRQMASK: 0 [ 10.948613] GPR00: c00801b92794 c0003082b3b0 c00801bc8000 c941bc00 [ 10.948613] GPR04: 0010 c00016001800 c0003082b420 [ 10.948613] GPR08: 001c 0100 53544154 c00801b92c98 [ 10.948613] GPR12: c00801b907f8 c00abfd02b00 c0003082bd00 0001372bd8b0 [ 10.948613] GPR16: ff20 c008008911b8 c0080089 11d0 [ 10.948613] GPR20: 0001 c0003082bbc0 c00801bc0a88 [ 10.948613] GPR24: c2950e30 0010 [ 10.948613] GPR28: c941bc00 0010 0020 c941bc00 [ 10.948660] NIP [c00801b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm] [ 10.948667] LR [c00801b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] [ 10.948673] Call Trace: [ 10.948675] [c0003082b3b0] [c941bca0] 0xc941bca0 (unreliable) [ 10.948680] [c0003082b460] [c00801b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm] [ 10.948687] [c0003082b550] [c09809b8] platform_probe+0x98/0x150 [ 10.948694] [c0003082b5d0] [c097bf2c] really_probe+0xfc/0x510 [ 10.948699] [c0003082b650] [c097c4bc] __driver_probe_device+0x17c/0x230 [ 10.948704] [c0003082b6d0] [c097c5c8] driver_probe_device+0x58/0x120 [ 10.948709] [c0003082b710] [c097ce0c] __driver_attach+0xfc/0x230 [ 10.948714] [c0003082b790] [c0978458] bus_for_each_dev+0xa8/0x130 [ 10.948718] [c0003082b7f0] [c097b2c4] driver_attach+0x34/0x50 [ 10.948722] [c0003082b810] [c097a508] bus_add_driver+0x1e8/0x350 [ 10.948729] [c0003082b8a0] [c097def8] driver_register+0x98/0x1a0 [ 10.948736] [c0003082b910] [c09804a8] __platform_driver_register+0x38/0x50 [ 10.948741] [c0003082b930] [c00801b92c10] papr_scm_init+0x3c/0x78 [papr_scm] [ 10.948747] [c0003082b960] [c0011ff0] do_one_initcall+0x60/0x2d0 [ 10.948753] [c0003082ba30] [c023627c] do_init_module+0x6c/0x2d0 [ 10.948760] [c0003082bab0] [c0239650] load_module+0x1e90/0x2290 [ 10.948765] [c0003082bc90] [c0239d9c] __do_sys_finit_module+0xdc/0x180 [ 10.948771] [c0003082bdb0] [c00335fc] system_call_exception+0x17c/0x350 [ 10.948777] [c0003082be10] [c000c53c] system_call_common+0xec/0x270 [ 10.948782] --- interrupt: c00 at 0x7fffa3f2f1d4 [ 10.948785] NIP: 7fffa3f2f1d4 LR: 7fffa456ea9c CTR: [ 10.948789] REGS: c0003082be80 TRAP: 0c00 Tainted: GE (5.18.0-rc7-next-20220520) [ 10.948793] MSR: 8280f033 CR: 2804 XER: [ 10.948805] IRQMASK: 0 [ 10.948805] GPR00: 0161 7fffd70550b0 7fffa4007300 0011 [ 10.948805] GPR04: 7fffa457ad30 0011 [ 10.948805] GPR08: [ 10.948805] GPR12: 7fffa4656580 0002 0001372bd8b0 [ 10.948805] GPR16: 000137300108 0001372c5c68 [ 10.948805] GPR20: 0001372c5ca0 00016f049240 7fffd70552d0 [ 10.948805] GPR24: 000137300128 0002 00016f038a80 [ 10.948805] GPR28: 7fffa457ad30 0002 00016f049240 [ 10.948849] NIP [7fffa3f2f1d4] 0x7fffa3f2f1d4 [ 10.948851] LR [7fffa456ea9c] 0x7fffa456ea9c [ 10.948854] ---
Re: [PATCH] livepatch: Remove klp_arch_set_pc() and asm/livepatch.h
Le 29/03/2022 à 13:22, Petr Mladek a écrit : > On Mon 2022-03-28 08:26:48, Christophe Leroy wrote: >> All three versions of klp_arch_set_pc() do exactly the same: they >> call ftrace_instruction_pointer_set(). >> >> Call ftrace_instruction_pointer_set() directly and remove >> klp_arch_set_pc(). >> >> As klp_arch_set_pc() was the only thing remaining in asm/livepatch.h >> on x86 and s390, remove asm/livepatch.h >> >> livepatch.h remains on powerpc but its content is exclusively used >> by powerpc specific code. >> >> Signed-off-by: Christophe Leroy > > Acked-by: Petr Mladek > > I am going to take it via livepatch/livepatch.git for 5.19. We are > already in the middle of the merge window and this is not critical. > I haven't seen it in linux-next. Do you still plan to take it for 5.19 ? Thanks Christophe
