* Re: [PATCH v7 1/3] riscv: Introduce CONFIG_RELOCATABLE
From: Alexandre ghiti @ 2021-12-06 9:44 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: aou, linux-kernel, paulus, Paul Walmsley, linux-riscv,
alexandre.ghiti, linuxppc-dev
In-Reply-To: <5846825d-cd7e-5085-569e-17cfaf36630f@ghiti.fr>
@Palmer, can I do anything for that to be pulled in 5.17?
Thanks,
Alex
On 10/27/21 07:04, Alexandre ghiti wrote:
> Hi Palmer,
>
> On 10/26/21 11:29 PM, Palmer Dabbelt wrote:
>> On Sat, 09 Oct 2021 10:20:20 PDT (-0700), alex@ghiti.fr wrote:
>>> Arf, I have sent this patchset with the wrong email address. @Palmer
>>> tell me if you want me to resend it correctly.
>> Sorry for being kind of slow here. It's fine: there's a "From:" in
>> the patch, and git picks those up so it'll match the signed-off-by
>> line. I send pretty much all my patches that way, as I never managed
>> to get my Google address working correctly.
>>
>>> Thanks,
>>>
>>> Alex
>>>
>>> On 10/9/21 7:12 PM, Alexandre Ghiti wrote:
>>>> From: Alexandre Ghiti <alex@ghiti.fr>
>>>>
>>>> This config allows to compile 64b kernel as PIE and to relocate it at
>>>> any virtual address at runtime: this paves the way to KASLR.
>>>> Runtime relocation is possible since relocation metadata are
>>>> embedded into
>>>> the kernel.
>> IMO this should really be user selectable, at a bare minimum so it's
>> testable.
>> I just sent along a patch to do that (my power's off at home, so email
>> is a bit
>> wacky right now).
>>
>> I haven't put this on for-next yet as I'm not sure if you had a fix
>> for the
>> kasan issue (which IIUC would conflict with this).
>
> The kasan issue only revealed that I need to move the kasan shadow
> memory around with sv48 support, that's not related to the relocatable
> kernel.
>
> Thanks,
>
> Alex
>
>
>>>> Note that relocating at runtime introduces an overhead even if the
>>>> kernel is loaded at the same address it was linked at and that the
>>>> compiler
>>>> options are those used in arm64 which uses the same RELA relocation
>>>> format.
>>>>
>>>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>>>> ---
>>>> arch/riscv/Kconfig | 12 ++++++++
>>>> arch/riscv/Makefile | 7 +++--
>>>> arch/riscv/kernel/vmlinux.lds.S | 6 ++++
>>>> arch/riscv/mm/Makefile | 4 +++
>>>> arch/riscv/mm/init.c | 54 ++++++++++++++++++++++++++++++++-
>>>> 5 files changed, 80 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>>>> index ea16fa2dd768..043ba92559fa 100644
>>>> --- a/arch/riscv/Kconfig
>>>> +++ b/arch/riscv/Kconfig
>>>> @@ -213,6 +213,18 @@ config PGTABLE_LEVELS
>>>> config LOCKDEP_SUPPORT
>>>> def_bool y
>>>>
>>>> +config RELOCATABLE
>>>> + bool
>>>> + depends on MMU && 64BIT && !XIP_KERNEL
>>>> + help
>>>> + This builds a kernel as a Position Independent Executable
>>>> (PIE),
>>>> + which retains all relocation metadata required to
>>>> relocate the
>>>> + kernel binary at runtime to a different virtual address
>>>> than the
>>>> + address it was linked at.
>>>> + Since RISCV uses the RELA relocation format, this requires a
>>>> + relocation pass at runtime even if the kernel is loaded
>>>> at the
>>>> + same address it was linked at.
>>>> +
>>>> source "arch/riscv/Kconfig.socs"
>>>> source "arch/riscv/Kconfig.erratas"
>>>>
>>>> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
>>>> index 0eb4568fbd29..2f509915f246 100644
>>>> --- a/arch/riscv/Makefile
>>>> +++ b/arch/riscv/Makefile
>>>> @@ -9,9 +9,12 @@
>>>> #
>>>>
>>>> OBJCOPYFLAGS := -O binary
>>>> -LDFLAGS_vmlinux :=
>>>> +ifeq ($(CONFIG_RELOCATABLE),y)
>>>> + LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro
>>>> + KBUILD_CFLAGS += -fPIE
>>>> +endif
>>>> ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
>>>> - LDFLAGS_vmlinux := --no-relax
>>>> + LDFLAGS_vmlinux += --no-relax
>>>> KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
>>>> CC_FLAGS_FTRACE := -fpatchable-function-entry=8
>>>> endif
>>>> diff --git a/arch/riscv/kernel/vmlinux.lds.S
>>>> b/arch/riscv/kernel/vmlinux.lds.S
>>>> index 5104f3a871e3..862a8c09723c 100644
>>>> --- a/arch/riscv/kernel/vmlinux.lds.S
>>>> +++ b/arch/riscv/kernel/vmlinux.lds.S
>>>> @@ -133,6 +133,12 @@ SECTIONS
>>>>
>>>> BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0)
>>>>
>>>> + .rela.dyn : ALIGN(8) {
>>>> + __rela_dyn_start = .;
>>>> + *(.rela .rela*)
>>>> + __rela_dyn_end = .;
>>>> + }
>>>> +
>>>> #ifdef CONFIG_EFI
>>>> . = ALIGN(PECOFF_SECTION_ALIGNMENT);
>>>> __pecoff_data_virt_size = ABSOLUTE(. - __pecoff_text_end);
>>>> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
>>>> index 7ebaef10ea1b..2d33ec574bbb 100644
>>>> --- a/arch/riscv/mm/Makefile
>>>> +++ b/arch/riscv/mm/Makefile
>>>> @@ -1,6 +1,10 @@
>>>> # SPDX-License-Identifier: GPL-2.0-only
>>>>
>>>> CFLAGS_init.o := -mcmodel=medany
>>>> +ifdef CONFIG_RELOCATABLE
>>>> +CFLAGS_init.o += -fno-pie
>>>> +endif
>>>> +
>>>> ifdef CONFIG_FTRACE
>>>> CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
>>>> CFLAGS_REMOVE_cacheflush.o = $(CC_FLAGS_FTRACE)
>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>>>> index c0cddf0fc22d..42041c12d496 100644
>>>> --- a/arch/riscv/mm/init.c
>>>> +++ b/arch/riscv/mm/init.c
>>>> @@ -20,6 +20,9 @@
>>>> #include <linux/dma-map-ops.h>
>>>> #include <linux/crash_dump.h>
>>>> #include <linux/hugetlb.h>
>>>> +#ifdef CONFIG_RELOCATABLE
>>>> +#include <linux/elf.h>
>>>> +#endif
>>>>
>>>> #include <asm/fixmap.h>
>>>> #include <asm/tlbflush.h>
>>>> @@ -103,7 +106,7 @@ static void __init print_vm_layout(void)
>>>> print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
>>>> (unsigned long)high_memory);
>>>> #ifdef CONFIG_64BIT
>>>> - print_mlm("kernel", (unsigned long)KERNEL_LINK_ADDR,
>>>> + print_mlm("kernel", (unsigned long)kernel_map.virt_addr,
>>>> (unsigned long)ADDRESS_SPACE_END);
>>>> #endif
>>>> }
>>>> @@ -518,6 +521,44 @@ static __init pgprot_t pgprot_from_va(uintptr_t
>>>> va)
>>>> #error "setup_vm() is called from head.S before relocate so it
>>>> should not use absolute addressing."
>>>> #endif
>>>>
>>>> +#ifdef CONFIG_RELOCATABLE
>>>> +extern unsigned long __rela_dyn_start, __rela_dyn_end;
>>>> +
>>>> +static void __init relocate_kernel(void)
>>>> +{
>>>> + Elf64_Rela *rela = (Elf64_Rela *)&__rela_dyn_start;
>>>> + /*
>>>> + * This holds the offset between the linked virtual address and
>>>> the
>>>> + * relocated virtual address.
>>>> + */
>>>> + uintptr_t reloc_offset = kernel_map.virt_addr - KERNEL_LINK_ADDR;
>>>> + /*
>>>> + * This holds the offset between kernel linked virtual address and
>>>> + * physical address.
>>>> + */
>>>> + uintptr_t va_kernel_link_pa_offset = KERNEL_LINK_ADDR -
>>>> kernel_map.phys_addr;
>>>> +
>>>> + for ( ; rela < (Elf64_Rela *)&__rela_dyn_end; rela++) {
>>>> + Elf64_Addr addr = (rela->r_offset - va_kernel_link_pa_offset);
>>>> + Elf64_Addr relocated_addr = rela->r_addend;
>>>> +
>>>> + if (rela->r_info != R_RISCV_RELATIVE)
>>>> + continue;
>>>> +
>>>> + /*
>>>> + * Make sure to not relocate vdso symbols like rt_sigreturn
>>>> + * which are linked from the address 0 in vmlinux since
>>>> + * vdso symbol addresses are actually used as an offset from
>>>> + * mm->context.vdso in VDSO_OFFSET macro.
>>>> + */
>>>> + if (relocated_addr >= KERNEL_LINK_ADDR)
>>>> + relocated_addr += reloc_offset;
>>>> +
>>>> + *(Elf64_Addr *)addr = relocated_addr;
>>>> + }
>>>> +}
>>>> +#endif /* CONFIG_RELOCATABLE */
>>>> +
>>>> #ifdef CONFIG_XIP_KERNEL
>>>> static void __init create_kernel_page_table(pgd_t *pgdir,
>>>> __always_unused bool early)
>>>> @@ -625,6 +666,17 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>>>> BUG_ON((kernel_map.virt_addr + kernel_map.size) >
>>>> ADDRESS_SPACE_END - SZ_4K);
>>>> #endif
>>>>
>>>> +#ifdef CONFIG_RELOCATABLE
>>>> + /*
>>>> + * Early page table uses only one PGDIR, which makes it possible
>>>> + * to map PGDIR_SIZE aligned on PGDIR_SIZE: if the relocation
>>>> offset
>>>> + * makes the kernel cross over a PGDIR_SIZE boundary, raise a bug
>>>> + * since a part of the kernel would not get mapped.
>>>> + */
>>>> + BUG_ON(PGDIR_SIZE - (kernel_map.virt_addr & (PGDIR_SIZE - 1)) <
>>>> kernel_map.size);
>>>> + relocate_kernel();
>>>> +#endif
>>>> +
>>>> pt_ops.alloc_pte = alloc_pte_early;
>>>> pt_ops.get_pte_virt = get_pte_virt_early;
>>>> #ifndef __PAGETABLE_PMD_FOLDED
^ permalink raw reply
* [PATCH 4/4] powerpc/perf: Add data source encodings for power10 platform
From: Kajol Jain @ 2021-12-06 9:17 UTC (permalink / raw)
To: mpe, linuxppc-dev, linux-kernel, peterz, mingo, acme, jolsa,
namhyung, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, linux-perf-users, yao.jin, maddy,
paulus, kan.liang
In-Reply-To: <20211206091749.87585-1-kjain@linux.ibm.com>
The code represent memory/cache level data based on PERF_MEM_LVL_*
namespace, which is in the process of deprication in the favour of
newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_} fields.
Add data source encodings to represent cache/memory data based on
newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_} fields.
Add data source encodings to represent data coming from local
memory/Remote memory/distant memory and remote/distant cache hits.
Inorder to represent data coming from OpenCAPI cache/memory, we use
LVLNUM "PMEM" field which is used to present persistent memory accesses.
Result in power10 system with patch changes:
localhost:# ./perf mem report --sort="mem,sym,dso" --stdio
# Overhead Samples Memory access Symbol Shared Object
# ........ ............ ........................ .......................... ................
#
29.46% 2331 L1 or L1 hit [.] __random libc-2.28.so
23.11% 2121 L1 or L1 hit [.] producer_populate_cache producer_consumer
18.56% 1758 L1 or L1 hit [.] __random_r libc-2.28.so
15.64% 1559 L2 or L2 hit [.] __random libc-2.28.so
.....
0.09% 5 Remote socket, same board Any cache hit [.] __random libc-2.28.so
0.07% 4 Remote socket, same board Any cache hit [.] __random libc-2.28.so
.....
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/isa207-common.c | 54 ++++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 6c6bc8b7d887..4037ea652522 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -229,13 +229,28 @@ static inline u64 isa207_find_source(u64 idx, u32 sub_idx)
ret = PH(LVL, L3) | LEVEL(L3) | P(SNOOP, HIT);
break;
case 4:
- if (sub_idx <= 1)
- ret = PH(LVL, LOC_RAM);
- else if (sub_idx > 1 && sub_idx <= 2)
- ret = PH(LVL, REM_RAM1);
- else
- ret = PH(LVL, REM_RAM2);
- ret |= P(SNOOP, HIT);
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+ ret = P(SNOOP, HIT);
+
+ if (sub_idx == 1)
+ ret |= PH(LVL, LOC_RAM) | LEVEL(RAM);
+ else if (sub_idx == 2 || sub_idx == 3)
+ ret |= P(LVL, HIT) | LEVEL(PMEM);
+ else if (sub_idx == 4)
+ ret |= PH(LVL, REM_RAM1) | REM | LEVEL(RAM) | P(HOPS, 2);
+ else if (sub_idx == 5 || sub_idx == 7)
+ ret |= P(LVL, HIT) | LEVEL(PMEM) | REM;
+ else if (sub_idx == 6)
+ ret |= PH(LVL, REM_RAM2) | REM | LEVEL(RAM) | P(HOPS, 3);
+ } else {
+ if (sub_idx <= 1)
+ ret = PH(LVL, LOC_RAM);
+ else if (sub_idx > 1 && sub_idx <= 2)
+ ret = PH(LVL, REM_RAM1);
+ else
+ ret = PH(LVL, REM_RAM2);
+ ret |= P(SNOOP, HIT);
+ }
break;
case 5:
if (cpu_has_feature(CPU_FTR_ARCH_31)) {
@@ -261,11 +276,26 @@ static inline u64 isa207_find_source(u64 idx, u32 sub_idx)
}
break;
case 6:
- ret = PH(LVL, REM_CCE2);
- if ((sub_idx == 0) || (sub_idx == 2))
- ret |= P(SNOOP, HIT);
- else if ((sub_idx == 1) || (sub_idx == 3))
- ret |= P(SNOOP, HITM);
+ if (cpu_has_feature(CPU_FTR_ARCH_31)) {
+ if (sub_idx == 0)
+ ret = PH(LVL, REM_CCE1) | LEVEL(ANY_CACHE) | REM |
+ P(SNOOP, HIT) | P(HOPS, 2);
+ else if (sub_idx == 1)
+ ret = PH(LVL, REM_CCE1) | LEVEL(ANY_CACHE) | REM |
+ P(SNOOP, HITM) | P(HOPS, 2);
+ else if (sub_idx == 2)
+ ret = PH(LVL, REM_CCE2) | LEVEL(ANY_CACHE) | REM |
+ P(SNOOP, HIT) | P(HOPS, 3);
+ else if (sub_idx == 3)
+ ret = PH(LVL, REM_CCE2) | LEVEL(ANY_CACHE) | REM |
+ P(SNOOP, HITM) | P(HOPS, 3);
+ } else {
+ ret = PH(LVL, REM_CCE2);
+ if (sub_idx == 0 || sub_idx == 2)
+ ret |= P(SNOOP, HIT);
+ else if (sub_idx == 1 || sub_idx == 3)
+ ret |= P(SNOOP, HITM);
+ }
break;
case 7:
ret = PM(LVL, L1);
--
2.27.0
^ permalink raw reply related
* [PATCH 3/4] powerpc/perf: Add encodings to represent data based on newer composite PERF_MEM_LVLNUM* fields
From: Kajol Jain @ 2021-12-06 9:17 UTC (permalink / raw)
To: mpe, linuxppc-dev, linux-kernel, peterz, mingo, acme, jolsa,
namhyung, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, linux-perf-users, yao.jin, maddy,
paulus, kan.liang
In-Reply-To: <20211206091749.87585-1-kjain@linux.ibm.com>
The code represent data coming from L1/L2/L3 cache hits based on
PERF_MEM_LVL_* namespace, which is in the process of deprecation in
the favour of newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_}
fields.
Add data source encodings to represent L1/L2/L3 cache hits based on
newer composite PERF_MEM_{LVLNUM_,REMOTE_,SNOOPX_,HOPS_} fields for
power10 and older platforms
Result in power9 system without patch changes:
localhost:# ./perf mem report --sort="mem,sym,dso" --stdio
# Overhead Samples Memory access Symbol Shared Object
# ........ ............ ........................ ................................. ................
#
29.51% 1 L2 hit [k] perf_event_exec [kernel.vmlinux]
27.05% 1 L1 hit [k] perf_ctx_unlock [kernel.vmlinux]
13.93% 1 L1 hit [k] vtime_delta [kernel.vmlinux]
13.11% 1 L1 hit [k] prepend_path.isra.11 [kernel.vmlinux]
8.20% 1 L1 hit [.] 00000038.plt_call.__GI_strlen libc-2.28.so
8.20% 1 L1 hit [k] perf_event_interrupt [kernel.vmlinux]
Result in power9 system with patch changes:
localhost:# ./perf mem report --sort="mem,sym,dso" --stdio
# Overhead Samples Memory access Symbol Shared Object
# ........ ............ ........................ .......................... ................
#
36.63% 1 L2 or L2 hit [k] perf_event_exec [kernel.vmlinux]
25.50% 1 L1 or L1 hit [k] vtime_delta [kernel.vmlinux]
13.12% 1 L1 or L1 hit [k] unmap_region [kernel.vmlinux]
12.62% 1 L1 or L1 hit [k] perf_sample_event_took [kernel.vmlinux]
6.93% 1 L1 or L1 hit [k] perf_ctx_unlock [kernel.vmlinux]
5.20% 1 L1 or L1 hit [.] __memcpy_power7 libc-2.28.so
Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/isa207-common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 7ea873ab2e6f..6c6bc8b7d887 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -220,13 +220,13 @@ static inline u64 isa207_find_source(u64 idx, u32 sub_idx)
/* Nothing to do */
break;
case 1:
- ret = PH(LVL, L1);
+ ret = PH(LVL, L1) | LEVEL(L1) | P(SNOOP, HIT);
break;
case 2:
- ret = PH(LVL, L2);
+ ret = PH(LVL, L2) | LEVEL(L2) | P(SNOOP, HIT);
break;
case 3:
- ret = PH(LVL, L3);
+ ret = PH(LVL, L3) | LEVEL(L3) | P(SNOOP, HIT);
break;
case 4:
if (sub_idx <= 1)
--
2.27.0
^ permalink raw reply related
* [PATCH 2/4] tools/perf: Add new macros for mem_hops field
From: Kajol Jain @ 2021-12-06 9:17 UTC (permalink / raw)
To: mpe, linuxppc-dev, linux-kernel, peterz, mingo, acme, jolsa,
namhyung, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, linux-perf-users, yao.jin, maddy,
paulus, kan.liang
In-Reply-To: <20211206091749.87585-1-kjain@linux.ibm.com>
Add new macros for mem_hops field which can be used to
represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0 which, corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket and board level data.
Also add corresponding strings in the mem_hops array to
represent mem_hop field data in perf_mem__lvl_scnprintf function
Incase mem_hops field is used, PERF_MEM_LVLNUM field also need
to be set inorder to represent the data source. Hence printing
data source via PERF_MEM_LVL field can be skip in that scenario.
For ex: Encodings for mem_hops fields with L2 cache:
L2 - local L2
L2 | REMOTE | HOPS_0 - remote core, same node L2
L2 | REMOTE | HOPS_1 - remote node, same socket L2
L2 | REMOTE | HOPS_2 - remote socket, same board L2
L2 | REMOTE | HOPS_3 - remote board L2
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
tools/include/uapi/linux/perf_event.h | 5 ++++-
tools/perf/util/mem-events.c | 29 +++++++++++++++++----------
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h
index bd8860eeb291..4cd39aaccbe7 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -1332,7 +1332,10 @@ union perf_mem_data_src {
/* hop level */
#define PERF_MEM_HOPS_0 0x01 /* remote core, same node */
-/* 2-7 available */
+#define PERF_MEM_HOPS_1 0x02 /* remote node, same socket */
+#define PERF_MEM_HOPS_2 0x03 /* remote socket, same board */
+#define PERF_MEM_HOPS_3 0x04 /* remote board */
+/* 5-7 available */
#define PERF_MEM_HOPS_SHIFT 43
#define PERF_MEM_S(a, s) \
diff --git a/tools/perf/util/mem-events.c b/tools/perf/util/mem-events.c
index 3167b4628b6d..ed0ab838bcc5 100644
--- a/tools/perf/util/mem-events.c
+++ b/tools/perf/util/mem-events.c
@@ -309,6 +309,9 @@ static const char * const mem_hops[] = {
* to be set with mem_hops field.
*/
"core, same node",
+ "node, same socket",
+ "socket, same board",
+ "board",
};
int perf_mem__lvl_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
@@ -316,7 +319,7 @@ int perf_mem__lvl_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
size_t i, l = 0;
u64 m = PERF_MEM_LVL_NA;
u64 hit, miss;
- int printed;
+ int printed = 0;
if (mem_info)
m = mem_info->data_src.mem_lvl;
@@ -335,18 +338,22 @@ int perf_mem__lvl_scnprintf(char *out, size_t sz, struct mem_info *mem_info)
l += 7;
}
- if (mem_info && mem_info->data_src.mem_hops)
+ /*
+ * Incase mem_hops field is set, we can skip printing data source via
+ * PERF_MEM_LVL namespace.
+ */
+ if (mem_info && mem_info->data_src.mem_hops) {
l += scnprintf(out + l, sz - l, "%s ", mem_hops[mem_info->data_src.mem_hops]);
-
- printed = 0;
- for (i = 0; m && i < ARRAY_SIZE(mem_lvl); i++, m >>= 1) {
- if (!(m & 0x1))
- continue;
- if (printed++) {
- strcat(out, " or ");
- l += 4;
+ } else {
+ for (i = 0; m && i < ARRAY_SIZE(mem_lvl); i++, m >>= 1) {
+ if (!(m & 0x1))
+ continue;
+ if (printed++) {
+ strcat(out, " or ");
+ l += 4;
+ }
+ l += scnprintf(out + l, sz - l, mem_lvl[i]);
}
- l += scnprintf(out + l, sz - l, mem_lvl[i]);
}
if (mem_info && mem_info->data_src.mem_lvl_num) {
--
2.27.0
^ permalink raw reply related
* [PATCH 1/4] perf: Add new macros for mem_hops field
From: Kajol Jain @ 2021-12-06 9:17 UTC (permalink / raw)
To: mpe, linuxppc-dev, linux-kernel, peterz, mingo, acme, jolsa,
namhyung, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, linux-perf-users, yao.jin, maddy,
paulus, kan.liang
In-Reply-To: <20211206091749.87585-1-kjain@linux.ibm.com>
Add new macros for mem_hops field which can be used to
represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0, which corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket and board level data.
For ex: Encodings for mem_hops fields with L2 cache:
L2 - local L2
L2 | REMOTE | HOPS_0 - remote core, same node L2
L2 | REMOTE | HOPS_1 - remote node, same socket L2
L2 | REMOTE | HOPS_2 - remote socket, same board L2
L2 | REMOTE | HOPS_3 - remote board L2
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
include/uapi/linux/perf_event.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bd8860eeb291..1b65042ab1db 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -1332,7 +1332,10 @@ union perf_mem_data_src {
/* hop level */
#define PERF_MEM_HOPS_0 0x01 /* remote core, same node */
-/* 2-7 available */
+#define PERF_MEM_HOPS_1 0x02 /* remote node, same socket */
+#define PERF_MEM_HOPS_2 0x03 /* remote socket, same board */
+#define PERF_MEM_HOPS_3 0x04 /* remote board */
+/* 5-7 available */
#define PERF_MEM_HOPS_SHIFT 43
#define PERF_MEM_S(a, s) \
--
2.27.0
^ permalink raw reply related
* [PATCH 0/4] perf: Add new macros for mem_hops field
From: Kajol Jain @ 2021-12-06 9:17 UTC (permalink / raw)
To: mpe, linuxppc-dev, linux-kernel, peterz, mingo, acme, jolsa,
namhyung, ak
Cc: mark.rutland, songliubraving, atrajeev, daniel, rnsastry,
alexander.shishkin, kjain, ast, linux-perf-users, yao.jin, maddy,
paulus, kan.liang
Patchset adds new macros for mem_hops field which can be
used to represent remote-node, socket and board level details.
Currently the code had macro for HOPS_0, which corresponds
to data coming from another core but same node.
Add new macros for HOPS_1 to HOPS_3 to represent
remote-node, socket and board level data.
For ex: Encodings for mem_hops fields with L2 cache:
L2 - local L2
L2 | REMOTE | HOPS_0 - remote core, same node L2
L2 | REMOTE | HOPS_1 - remote node, same socket L2
L2 | REMOTE | HOPS_2 - remote socket, same board L2
L2 | REMOTE | HOPS_3 - remote board L2
Patch 1 & 2 adds tool and kernel side changes to add new macros for
mem_hops field
Patch 3 add data source encodings for power10 and older platforms
to represent data based on newer composite PERF_MEM_LVLNUM* fields
Patch 4 add data source encodings with proper sub_index used to
represent memory/cache level data for power10 platform.
Kajol Jain (4):
perf: Add new macros for mem_hops field
tools/perf: Add new macros for mem_hops field
powerpc/perf: Add encodings to represent data based on newer composite
PERF_MEM_LVLNUM* fields
powerpc/perf: Add data source encodings for power10 platform
arch/powerpc/perf/isa207-common.c | 60 ++++++++++++++++++++-------
include/uapi/linux/perf_event.h | 5 ++-
tools/include/uapi/linux/perf_event.h | 5 ++-
tools/perf/util/mem-events.c | 29 ++++++++-----
4 files changed, 71 insertions(+), 28 deletions(-)
--
2.27.0
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-06 9:07 UTC (permalink / raw)
To: mbizon@freebox.fr; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <b39cea045b4317a83b4605f2aeb8a88bcc44b1d7.camel@freebox.fr>
Le 06/12/2021 à 09:47, Maxime Bizon a écrit :
>
> On Mon, 2021-12-06 at 07:03 +0000, Christophe Leroy wrote:
>
>> Is it worth it ? I have the feeling that's more a corner case.
>
> probably not since it's not an easy fix
>
> I'm running on the edge wrt BAT usage on my 2GB board, it's not that
> common I guess.
>
Looks like you can win something if you take the patch I just sent and
replace the memblock_phys_alloc(k_size, k_size) by
memblock_phys_alloc_range(k_size, k_size, 0, MEMBLOCK_ALLOC_ANYWHERE)
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-06 8:47 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cea77e1e-9972-33cf-3ef8-e0be5ff26b63@csgroup.eu>
On Mon, 2021-12-06 at 07:03 +0000, Christophe Leroy wrote:
> Is it worth it ? I have the feeling that's more a corner case.
probably not since it's not an easy fix
I'm running on the edge wrt BAT usage on my 2GB board, it's not that
common I guess.
--
Maxime
^ permalink raw reply
* [PATCH] powerpc/32s: Fix BATs allocation for KASAN
From: Christophe Leroy @ 2021-12-06 8:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Maxime Bizon, stable@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
It has been reported some configuration where the kernel doesn't
boot with KASAN enabled.
This is due to wrong BAT allocation for the KASAN area:
---[ Data Block Address Translation ]---
0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw m
1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw m
2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw m
3: 0xf8000000-0xf9ffffff 0x2a000000 32M Kernel rw m
4: 0xfa000000-0xfdffffff 0x2c000000 64M Kernel rw m
A BAT must have both virtual and physical addresses alignment matching
the size of the BAT. This is not the case for BAT 4 above.
Fix kasan_init_region() by using block_size() function that is in
book3s32/mmu.c. To be able to reuse it here, make it non static and
change its name to bat_block_size() in order to avoid name conflict
with block_size() defined in <linux/blkdev.h>
Also reuse find_free_bat() to avoid an error message from setbat()
when no BAT is available.
With this change we get correct alignment for BATs:
---[ Data Block Address Translation ]---
0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw
1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw
2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw
3: 0xf8000000-0xfbffffff 0x2c000000 64M Kernel rw
4: 0xfc000000-0xfdffffff 0x2a000000 32M Kernel rw
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Fixes: 7974c4732642 ("powerpc/32s: Implement dedicated kasan_init_region()")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 +
arch/powerpc/mm/book3s32/mmu.c | 10 ++---
arch/powerpc/mm/kasan/book3s_32.c | 43 ++++++++++---------
3 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
index f5be185cbdf8..5b45c648a8d9 100644
--- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
@@ -143,6 +143,8 @@ static __always_inline void update_user_segments(u32 val)
update_user_segment(15, val);
}
+int find_free_bat(void);
+unsigned int bat_block_size(unsigned long base, unsigned long top);
#endif /* !__ASSEMBLY__ */
/* We happily ignore the smaller BATs on 601, we don't actually use
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index cb48e4a5106d..9e7714a861bf 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -76,7 +76,7 @@ unsigned long p_block_mapped(phys_addr_t pa)
return 0;
}
-static int find_free_bat(void)
+int find_free_bat(void)
{
int b;
int n = mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4;
@@ -100,7 +100,7 @@ static int find_free_bat(void)
* - block size has to be a power of two. This is calculated by finding the
* highest bit set to 1.
*/
-static unsigned int block_size(unsigned long base, unsigned long top)
+unsigned int bat_block_size(unsigned long base, unsigned long top)
{
unsigned int max_size = SZ_256M;
unsigned int base_shift = (ffs(base) - 1) & 31;
@@ -145,7 +145,7 @@ static unsigned long __init __mmu_mapin_ram(unsigned long base, unsigned long to
int idx;
while ((idx = find_free_bat()) != -1 && base != top) {
- unsigned int size = block_size(base, top);
+ unsigned int size = bat_block_size(base, top);
if (size < 128 << 10)
break;
@@ -204,12 +204,12 @@ void mmu_mark_initmem_nx(void)
unsigned long size;
for (i = 0; i < nb - 1 && base < top && top - base > (128 << 10);) {
- size = block_size(base, top);
+ size = bat_block_size(base, top);
setibat(i++, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT);
base += size;
}
if (base < top) {
- size = block_size(base, top);
+ size = bat_block_size(base, top);
size = max(size, 128UL << 10);
if ((top - base) > size) {
size <<= 1;
diff --git a/arch/powerpc/mm/kasan/book3s_32.c b/arch/powerpc/mm/kasan/book3s_32.c
index 202bd260a009..c2ff93c63dfa 100644
--- a/arch/powerpc/mm/kasan/book3s_32.c
+++ b/arch/powerpc/mm/kasan/book3s_32.c
@@ -11,32 +11,33 @@ int __init kasan_init_region(void *start, size_t size)
unsigned long k_start = (unsigned long)kasan_mem_to_shadow(start);
unsigned long k_end = (unsigned long)kasan_mem_to_shadow(start + size);
unsigned long k_cur = k_start;
- int k_size = k_end - k_start;
- int k_size_base = 1 << (ffs(k_size) - 1);
int ret;
void *block;
- block = memblock_alloc(k_size, k_size_base);
-
- if (block && k_size_base >= SZ_128K && k_start == ALIGN(k_start, k_size_base)) {
- int k_size_more = 1 << (ffs(k_size - k_size_base) - 1);
-
- setbat(-1, k_start, __pa(block), k_size_base, PAGE_KERNEL);
- if (k_size_more >= SZ_128K)
- setbat(-1, k_start + k_size_base, __pa(block) + k_size_base,
- k_size_more, PAGE_KERNEL);
- if (v_block_mapped(k_start))
- k_cur = k_start + k_size_base;
- if (v_block_mapped(k_start + k_size_base))
- k_cur = k_start + k_size_base + k_size_more;
-
- update_bats();
+ while (k_cur < k_end) {
+ unsigned int k_size = bat_block_size(k_cur, k_end);
+ phys_addr_t phys;
+ int idx = find_free_bat();
+
+ if (idx == -1)
+ break;
+ if (k_size < SZ_128K)
+ break;
+ phys = memblock_phys_alloc(k_size, k_size);
+ if (!phys)
+ break;
+
+ setbat(idx, k_cur, phys, k_size, PAGE_KERNEL);
+ k_cur += k_size;
}
+ if (k_cur != k_start)
+ update_bats();
- if (!block)
- block = memblock_alloc(k_size, PAGE_SIZE);
- if (!block)
- return -ENOMEM;
+ if (k_cur < k_end) {
+ block = memblock_alloc(k_end - k_cur, PAGE_SIZE);
+ if (!block)
+ return -ENOMEM;
+ }
ret = kasan_init_shadow_page_tables(k_start, k_end);
if (ret)
--
2.33.1
^ permalink raw reply related
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-06 7:03 UTC (permalink / raw)
To: Maxime Bizon; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211205214408.GC29658@sakura>
Le 05/12/2021 à 22:44, Maxime Bizon a écrit :
>
>
> On Sunday 05 Dec 2021 à 18:11:59 (+0000), Christophe Leroy wrote:
>
>>> Is BAT5 needed here ?
>>
>> Sure it is, because that's were kernel expects lowmem to be mapped.
>> Allthough the kernel will unlikely access the 128M reserved for KASAN
>> directly, the other 128M are still needed.
>>
>
> Yes that was my point
>
> I'm wondering if for specific PAGE_OFFSET values, __mmu_mapin_ram()
> ends using a BAT to map exactly the KASAN area, thus wasting it
> because the kernel would never/rarely access it.
Is it worth it ? I have the feeling that's more a corner case.
>
> Or worse, it could consume the latest BAT available, and there would
> be none left for the actual KASAN vm area
Even more.
>
> Maybe mmu_mapin_ram() could clamp top to KASAN phys start.
>
An alternative could be to try and use for KASAN some memory which is
not available in the linear mapping.
For instance, in your case, you have move than 2G bytes mem I guess and
you are mapping 0x00000000 to 0x5fffffff. Maybe could use 0x6000000 up
for KASAN.
But I don't know how to proceed to do it that way. Today we use
memblock_alloc() which is the only memory allocator available at the
time we allocate KASAN shadow area. But memblock_alloc() allocates
memory from the directly accessible area.
Christophe
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-05 21:44 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <d39825e0-6b48-5ac1-662e-26186e730eaa@csgroup.eu>
On Sunday 05 Dec 2021 à 18:11:59 (+0000), Christophe Leroy wrote:
> > Is BAT5 needed here ?
>
> Sure it is, because that's were kernel expects lowmem to be mapped.
> Allthough the kernel will unlikely access the 128M reserved for KASAN
> directly, the other 128M are still needed.
>
Yes that was my point
I'm wondering if for specific PAGE_OFFSET values, __mmu_mapin_ram()
ends using a BAT to map exactly the KASAN area, thus wasting it
because the kernel would never/rarely access it.
Or worse, it could consume the latest BAT available, and there would
be none left for the actual KASAN vm area
Maybe mmu_mapin_ram() could clamp top to KASAN phys start.
--
Maxime
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-05 18:11 UTC (permalink / raw)
To: Maxime Bizon; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211205164217.GA29658@sakura>
Le 05/12/2021 à 17:42, Maxime Bizon a écrit :
>
>
> On Saturday 04 Dec 2021 à 17:42:44 (+0000), Christophe Leroy wrote:
>
>> I guess all the guard is in the comment ...
>>
>> /*
>> * Set up one of the I/D BAT (block address translation) register pairs.
>> * The parameters are not checked; in particular size must be a power
>> * of 2 between 128k and 256M.
>> */
>
> It's missing the aligment rule you just taught me, but it's arguably
> not the right place to teach ppc 101.
Indeed
>
>> Not sure it is that simple.
>>
>> I'm cooking a patch reusing the block_size() function in mm/book3s32/mmu.c
>
> Indeed it will handle cases that need more than 2 BATs.
Yes, that's the idea.
>
> Also when mem=2G, I have physical memory mapped twice:
>
> CONFIG_PAGE_OFFSET=0x80000000
> CONFIG_LOWMEM_SIZE=0x60000000
>
> 0: 0x80000000-0x8fffffff 0x00000000 256M Kernel rw m
> 1: 0x90000000-0x9fffffff 0x10000000 256M Kernel rw m
> 2: 0xa0000000-0xafffffff 0x20000000 256M Kernel rw m
> 3: 0xb0000000-0xbfffffff 0x30000000 256M Kernel rw m
> 4: 0xc0000000-0xcfffffff 0x40000000 256M Kernel rw m
> 5: 0xd0000000-0xdfffffff 0x50000000 256M Kernel rw m
> 6: 0xf0000000-0xf7ffffff 0x50000000 128M Kernel rw m
>
> BAT5 comes from __mmu_mapin_ram(), BAT6 from kasan init
>
> Is BAT5 needed here ?
Sure it is, because that's were kernel expects lowmem to be mapped.
Allthough the kernel will unlikely access the 128M reserved for KASAN
directly, the other 128M are still needed.
>
>
> Last one, with KASAN and the following layout, I have an non working
> kernel with VMALLOC_START > VMALLOC_END:
>
> mem=2G
> CONFIG_PAGE_OFFSET=0x80000000
> CONFIG_LOWMEM_SIZE=0x70000000
>
> [ 0.000000] * 0xf0000000..0xfe000000 : kasan shadow mem
> [ 0.000000] * 0xef7ff000..0xeffff000 : fixmap
> [ 0.000000] * 0xf1000000..0xef7ff000 : vmalloc & ioremap
>
>
> IIUC the safeguard is here:
>
> arch/powerpc/mm/init_32.c:
> /* The amount of lowmem must be within 0xF0000000 - KERNELBASE. */
> #if (CONFIG_LOWMEM_SIZE > (0xF0000000 - PAGE_OFFSET))
> #error "You must adjust CONFIG_LOWMEM_SIZE or CONFIG_KERNEL_START"
>
>
> but the definition needs to be adapted for KASAN=y and require 256
> more MB.
>
>
Hum.. Good point.
Christophe
^ permalink raw reply
* fbx_5.15 WARN_ON() at boot with CONFIG_DEBUG_VM
From: Maxime Bizon @ 2021-12-05 18:09 UTC (permalink / raw)
To: linuxppc-dev
Hello,
With CONFIG_DEBUG_VM=y, early_iounmap() triggers this:
VM_WARN_ON(pte_hw_valid(*ptep) && !pte_protnone(*ptep));
[ 0.292811] WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0x8c/0x21c
[ 0.301053] CPU: 0 PID: 1 Comm: swapper Tainted: G W 5.15.0+ #402
[ 0.308473] NIP: 8001d96c LR: 8001d960 CTR: 00000000
[ 0.313520] REGS: 810fbc10 TRAP: 0700 Tainted: G W (5.15.0+)
[ 0.320749] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 48008804 XER: 00000000
[ 0.327705]
[ 0.327705] GPR00: 8001d960 810fbcc0 810c8020 80ce4004 8001d8e0 80ce4004 00000000 810fbcd0
[ 0.327705] GPR08: 00000007 00000001 00000000 80950ed4 28000804 00000000 8000673c 00000000
[ 0.327705] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.327705] GPR24: 80d01ef8 80b8dca0 00000000 80d01000 ef801000 00000000 f021f79a 80ce4004
[ 0.363822] NIP [8001d96c] set_pte_at+0x8c/0x21c
[ 0.368462] LR [8001d960] set_pte_at+0x80/0x21c
[ 0.373009] Call Trace:
[ 0.375443] [810fbcc0] [8001d960] set_pte_at+0x80/0x21c (unreliable)
[ 0.381891] [810fbd30] [8001e8cc] map_kernel_page+0x120/0x1a4
[ 0.387707] [810fbda0] [80179a18] __set_fixmap+0x38/0x4c
[ 0.393096] [810fbdb0] [809a772c] early_iounmap+0x184/0x218
[ 0.398733] [810fbdf0] [80995db0] ioremap_legacy_serial_console+0x108/0x150
[ 0.405803] [810fbe20] [8099144c] do_one_initcall+0xe8/0x228
[ 0.411541] [810fbed0] [809916ec] kernel_init_freeable+0xdc/0x378
[ 0.417718] [810fbf20] [80006764] kernel_init+0x28/0x118
[ 0.423107] [810fbf40] [80016148] ret_from_kernel_thread+0x14/0x1c
[ 0.429380] Instruction dump:
[ 0.432349] 913e0004 7cbf2b78 915e0000 38610030 90c10030 4815a605 7fe3fb78 83a10030
[ 0.440363] 4815a5f9 813f0000 71290001 41820010 <0fe00000> 9361005c 93810060 93810060
[ 0.448553] ---[ end trace 523b05d3a0288818 ]---
--
Maxime
^ permalink raw reply
* [Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
From: bugzilla-daemon @ 2021-12-05 17:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215217-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215217
--- Comment #3 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
I tried your config under QEMU and it works. So I don't know how I could help.
>> =============================================================
>> OpenBIOS 1.1 [Jul 22 2021 22:33]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 2048M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jul 22 2021 22:33
>> [ppc] Kernel already loaded (0x01000000 + 0x00f39460) (initrd 0x0203a000 +
>> 0x001d1a3b)
>> [ppc] Kernel command line: noreboot
>> switching to new context:
OF stdout device is: /pci@f2000000/mac-io@c/escc@13000/ch-a@13020
Preparing to boot Linux version 5.16.0-rc3-PowerMacG4+
(chleroy@PO20335.IDSI0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 11.1.0, GNU ld
(GNU Binutils) 2.36.1) #669 SMP Sun Dec 5 18:41:30 CET 2021
Detected machine type: 00000400
command line:
memory layout at init:
memory_limit : 00000000 (16 MB aligned)
alloc_bottom : 01f3e000
alloc_top : 30000000
alloc_top_hi : 80000000
rmo_top : 30000000
ram_top : 80000000
found display : /pci@f2000000/QEMU,VGA@e, opening... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x01f3f000 -> 0x01f3e0a4
Device tree struct 0x01f40000 -> 0x7fde7ef8
Quiescing Open Firmware ...
Booting Linux via __start() @ 0x01000000 ...
Hello World !
Total memory = 2048MB; using 4096kB for hash table
Activating Kernel Userspace Execution Prevention
Activating Kernel Userspace Access Protection
Linux version 5.16.0-rc3-PowerMacG4+ (chleroy@PO20335.IDSI0.si.c-s.fr)
(powerpc64-linux-gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #669 SMP Sun
Dec 5 18:41:30 CET 2021
KASAN init done
ioremap() called early from pmac_feature_init+0x248/0xfe4. Use early_ioremap()
instead
Found UniNorth memory controller & host bridge @ 0xf8000000 revision: 0x07
Mapped at 0xf53bf000
ioremap() called early from probe_one_macio+0x228/0x414. Use early_ioremap()
instead
Found a Keylargo mac-io controller, rev: 0, mapped at 0x(ptrval)
PowerMac motherboard: PowerMac G4 AGP Graphics
ioremap() called early from udbg_scc_init+0x1dc/0x380. Use early_ioremap()
instead
boot stdout isn't a display !
Using PowerMac machine description
printk: bootconsole [udbg0] enabled
CPU maps initialized for 1 thread per core
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-05 16:42 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <5f4d36a1-695d-38a7-9ff9-d5af97f1a7e0@csgroup.eu>
On Saturday 04 Dec 2021 à 17:42:44 (+0000), Christophe Leroy wrote:
> I guess all the guard is in the comment ...
>
> /*
> * Set up one of the I/D BAT (block address translation) register pairs.
> * The parameters are not checked; in particular size must be a power
> * of 2 between 128k and 256M.
> */
It's missing the aligment rule you just taught me, but it's arguably
not the right place to teach ppc 101.
> Not sure it is that simple.
>
> I'm cooking a patch reusing the block_size() function in mm/book3s32/mmu.c
Indeed it will handle cases that need more than 2 BATs.
Also when mem=2G, I have physical memory mapped twice:
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_LOWMEM_SIZE=0x60000000
0: 0x80000000-0x8fffffff 0x00000000 256M Kernel rw m
1: 0x90000000-0x9fffffff 0x10000000 256M Kernel rw m
2: 0xa0000000-0xafffffff 0x20000000 256M Kernel rw m
3: 0xb0000000-0xbfffffff 0x30000000 256M Kernel rw m
4: 0xc0000000-0xcfffffff 0x40000000 256M Kernel rw m
5: 0xd0000000-0xdfffffff 0x50000000 256M Kernel rw m
6: 0xf0000000-0xf7ffffff 0x50000000 128M Kernel rw m
BAT5 comes from __mmu_mapin_ram(), BAT6 from kasan init
Is BAT5 needed here ?
Last one, with KASAN and the following layout, I have an non working
kernel with VMALLOC_START > VMALLOC_END:
mem=2G
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_LOWMEM_SIZE=0x70000000
[ 0.000000] * 0xf0000000..0xfe000000 : kasan shadow mem
[ 0.000000] * 0xef7ff000..0xeffff000 : fixmap
[ 0.000000] * 0xf1000000..0xef7ff000 : vmalloc & ioremap
IIUC the safeguard is here:
arch/powerpc/mm/init_32.c:
/* The amount of lowmem must be within 0xF0000000 - KERNELBASE. */
#if (CONFIG_LOWMEM_SIZE > (0xF0000000 - PAGE_OFFSET))
#error "You must adjust CONFIG_LOWMEM_SIZE or CONFIG_KERNEL_START"
but the definition needs to be adapted for KASAN=y and require 256
more MB.
--
Maxime
^ permalink raw reply
* [PATCH] macintosh:add const to of_device_id
From: Xiang wangx @ 2021-12-05 13:09 UTC (permalink / raw)
To: benh; +Cc: Xiang wangx, linuxppc-dev, linux-kernel
struct of_device_id should normally be const
Signed-off-by: Xiang wangx <wangxiang@cdjrlc.com>
---
drivers/macintosh/mediabay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index eab7e83c11c4..b17660c022eb 100644
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -703,7 +703,7 @@ static const struct mb_ops keylargo_mb_ops = {
* Therefore we do it all by polling the media bay once each tick.
*/
-static struct of_device_id media_bay_match[] =
+static const struct of_device_id media_bay_match[] =
{
{
.name = "media-bay",
--
2.20.1
^ permalink raw reply related
* [Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
From: bugzilla-daemon @ 2021-12-05 9:51 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215217-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215217
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Just rebuilt the kernel without KASAN but I still hit this bug.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 215217] Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
From: bugzilla-daemon @ 2021-12-05 8:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215217-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215217
--- Comment #1 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
POWER9 doesn't have KASAN.
Did you try G4 without KASAN ?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 215217] New: Kernel fails to boot at an early stage when built with GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
From: bugzilla-daemon @ 2021-12-04 22:48 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=215217
Bug ID: 215217
Summary: Kernel fails to boot at an early stage when built with
GCC_PLUGIN_LATENT_ENTROPY=y (PowerMac G4 3,6)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.16-rc3
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: erhard_f@mailbox.org
CC: christophe.leroy@csgroup.eu
Regression: No
Created attachment 299871
--> https://bugzilla.kernel.org/attachment.cgi?id=299871&action=edit
kernel .config (5.16-rc3, PowerMac G4 DP)
Get this on my PowerMac G4 DP when I build a kernel with
GCC_PLUGIN_LATENT_ENTROPY=y. The kernel gets decompressed but shortly
afterwards the machine freezes, displaying in black letters on an entirely
white screen:
done
found display : /pci@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@1,
opening...
Same kernel config built without GCC_PLUGIN_LATENT_ENTROPY just boots fine.
Happens on v5.15.5 and v5.16-rc3. I did not test other kernel versions yet.
My Talos II (Power9) on the other hand just works fine with a
GCC_PLUGIN_LATENT_ENTROPY=y built kernel.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-04 14:10 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <c7b4ef55-1deb-41f6-58cc-f8dc4477e90c@csgroup.eu>
On Saturday 04 Dec 2021 à 10:01:07 (+0000), Christophe Leroy wrote:
> In fact BAT4 is wrong. Both virtual and physical address of a 64M BAT
> must be 64M aligned. I think the display is wrong as well (You took it
oh so hardware does simple bitmask after all
I got fooled by the lack of guard in the bat setup code, so I assumed
magical hardware
> from ptdump ?), BEPI and BRPN must be anded with complement of BL.
yes that was ptdump code with seq_printf replaced by printk
ptdump code is correct but iif the bat addresses are correctly
aligned, maybe add a safeguard like this ?
index 85062ce2d849..f7c5cf62ef41 100644
--- a/arch/powerpc/mm/book3s32/mmu.c
+++ b/arch/powerpc/mm/book3s32/mmu.c
@@ -275,6 +279,10 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys,
(unsigned long long)phys);
return;
}
+
+ WARN_ON(!is_power_of_2(size));
+ WARN_ON((phys & (size - 1)));
+ WARN_ON((virt & (size - 1)));
bat = BATS[index];
> So here your 64M BAT maps 0xf8000000-0xfbffffff, therefore the address
> 0xfd3fce00 is not mapped by any BAT hence the OOPS.
ok I think I found the issue:
diff --git a/arch/powerpc/mm/kasan/book3s_32.c b/arch/powerpc/mm/kasan/book3s_32.c
index 35b287b0a8da..fcbb9a136c1a 100644
--- a/arch/powerpc/mm/kasan/book3s_32.c
+++ b/arch/powerpc/mm/kasan/book3s_32.c
@@ -12,14 +12,14 @@ int __init kasan_init_region(void *start, size_t size)
unsigned long k_end = (unsigned long)kasan_mem_to_shadow(start + size);
unsigned long k_cur = k_start;
int k_size = k_end - k_start;
- int k_size_base = 1 << (ffs(k_size) - 1);
+ int k_size_base = 1 << (fls(k_size) - 1);
int ret;
void *block;
block = memblock_alloc(k_size, k_size_base);
if (block && k_size_base >= SZ_128K && k_start == ALIGN(k_start, k_size_base)) {
- int shift = ffs(k_size - k_size_base);
+ int shift = fls(k_size - k_size_base);
int k_size_more = shift ? 1 << (shift - 1) : 0;
setbat(-1, k_start, __pa(block), k_size_base, PAGE_KERNEL);
--
Maxime
^ permalink raw reply related
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Maxime Bizon @ 2021-12-03 18:43 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <68bf4c39-53ce-f88f-383f-5defb1a36b1c@csgroup.eu>
On Fri, 2021-12-03 at 12:49 +0000, Christophe Leroy wrote:
Hello,
> I need to think a bit more about it to find the cleanest solution
> that works for all platforms.
Maybe related, when enabling KASAN on that same platform, it oopses early.
I have picked the patch "powerpc/32s: Fix shift-out-of-bounds in KASAN
init", and that does not fix it
For some mem= values like 769M, all BATs are used for kernel linear
mapping, and there are none left to map the KASAN shadow area in
kasan/book3s_32.c => no oops
If I don't compile kasan/book3s_32.c and use weak implementation => no
oops
But for mem=768M, it oopses
I added some debugs in kasan init and dumped BATs content (BAT 7 is my
debug BAT for uart)
[ 0.000000] kasan_init_region: start=0xc0000000 size:0x30000000
[ 0.000000] kasan_init_region: k_start:0xf8000000 k_end:0xfe000000 k_size:0x6000000 k_size_base=0x2000000
[ 0.000000] kasan_init_region: IF{} k_size_more:0x4000000
[ 0.000000] setbat index=3 virt:0xf8000000 phys:0x2a000000 size:0x2000000
[ 0.000000] setbat index=4 virt:0xfa000000 phys:0x2c000000 size:0x4000000
[ 0.000000] kasan_init_region: final k_cur=0xfe000000
[ 0.000000]
[ 0.000000] ---[ Data Block Address Translation ]---
[ 0.000000] 0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw m
[ 0.000000] 1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw m
[ 0.000000] 2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw m
[ 0.000000] 3: 0xf8000000-0xf9ffffff 0x2a000000 32M Kernel rw m
[ 0.000000] 4: 0xfa000000-0xfdffffff 0x2c000000 64M Kernel rw m
[ 0.000000] 5: -
[ 0.000000] 6: -
[ 0.000000] 7: 0xb0000000-0xb00fffff 0xe0000000 1M Kernel rw i g
[ 0.000000] BUG: Unable to handle kernel data access on read at 0xfd3fce00
[ 0.000000] Faulting instruction address: 0xc013ed84
[ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.000000] BE PAGE_SIZE=4K
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0+ #379
[ 0.000000] NIP: c013ed84 LR: c0140264 CTR: 00000020
[ 0.000000] REGS: c0b07dd0 TRAP: 0300 Not tainted (5.15.0+)
[ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 28222448 XER: 00000000
[ 0.000000] DAR: fd3fce00 DSISR: 20000000
[ 0.000000] GPR00: fd3fd000 c0b07e80 c09c8a20 0000003f 00001000 00000001 c08c67a8 e9fe7fff
[ 0.000000] GPR08: e9fe7000 fd3fce00 00000020 fd3fcfff 00000000 00000000 3ff9c5f0 3fffd79c
[ 0.000000] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 0.000000] GPR24: 00000000 feffffff 00000591 c0b22000 ffffffff 00000000 e9fe7000 00001000
[ 0.000000] NIP [c013ed84] kasan_check_range+0x98/0x2c0
[ 0.000000] LR [c0140264] memset+0x34/0x80
[ 0.000000] Call Trace:
[ 0.000000] [c0b07e80] [c08c630c] memblock_alloc_internal+0x9c/0x108 (unreliable)
[ 0.000000] [c0b07e90] [feffffff] 0xfeffffff
[ 0.000000] [c0b07eb0] [c08c67a8] memblock_alloc_try_nid+0xf4/0x128
[ 0.000000] [c0b07f30] [c08bb7ac] kasan_init_shadow_page_tables+0x84/0x1cc
[ 0.000000] [c0b07f60] [c08bba40] kasan_init+0xdc/0x184
[ 0.000000] [c0b07f90] [c08b8108] setup_arch+0x18/0x1c4
[ 0.000000] [c0b07fc0] [c08b3fd4] start_kernel+0x5c/0x2d4
[ 0.000000] [c0b07ff0] [000033c0] 0x33c0
[ 0.000000] Instruction dump:
[ 0.000000] 93e1000c 83c90000 83e90004 7fdffb79 83c10008 83e1000c 408201cc 2c030000
[ 0.000000] 39290008 41820034 554af87e 7d4903a6 <80690000> 81490004 7c6a5379 408201a8
It makes no sense to me that we get that fault with a valid BAT
covering that area, BAT are not supposed to be checked first ?
--
Maxime
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-04 17:42 UTC (permalink / raw)
To: Maxime Bizon; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20211204141031.GA23757@sakura>
Le 04/12/2021 à 15:10, Maxime Bizon a écrit :
>
> On Saturday 04 Dec 2021 à 10:01:07 (+0000), Christophe Leroy wrote:
>
>> In fact BAT4 is wrong. Both virtual and physical address of a 64M BAT
>> must be 64M aligned. I think the display is wrong as well (You took it
>
> oh so hardware does simple bitmask after all
>
> I got fooled by the lack of guard in the bat setup code, so I assumed
> magical hardware
I guess all the guard is in the comment ...
/*
* Set up one of the I/D BAT (block address translation) register pairs.
* The parameters are not checked; in particular size must be a power
* of 2 between 128k and 256M.
*/
void __init setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, pgprot_t prot)
>
>> from ptdump ?), BEPI and BRPN must be anded with complement of BL.
>
> yes that was ptdump code with seq_printf replaced by printk
>
> ptdump code is correct but iif the bat addresses are correctly
> aligned, maybe add a safeguard like this ?
>
> index 85062ce2d849..f7c5cf62ef41 100644
> --- a/arch/powerpc/mm/book3s32/mmu.c
> +++ b/arch/powerpc/mm/book3s32/mmu.c
> @@ -275,6 +279,10 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys,
> (unsigned long long)phys);
> return;
> }
> +
> + WARN_ON(!is_power_of_2(size));
> + WARN_ON((phys & (size - 1)));
> + WARN_ON((virt & (size - 1)));
> bat = BATS[index];
>
Yes we could add some check allthough I'd go for a 'pr_err()' like when
no BAT is available.
>
>> So here your 64M BAT maps 0xf8000000-0xfbffffff, therefore the address
>> 0xfd3fce00 is not mapped by any BAT hence the OOPS.
>
> ok I think I found the issue:
>
> diff --git a/arch/powerpc/mm/kasan/book3s_32.c b/arch/powerpc/mm/kasan/book3s_32.c
> index 35b287b0a8da..fcbb9a136c1a 100644
> --- a/arch/powerpc/mm/kasan/book3s_32.c
> +++ b/arch/powerpc/mm/kasan/book3s_32.c
> @@ -12,14 +12,14 @@ int __init kasan_init_region(void *start, size_t size)
> unsigned long k_end = (unsigned long)kasan_mem_to_shadow(start + size);
> unsigned long k_cur = k_start;
> int k_size = k_end - k_start;
> - int k_size_base = 1 << (ffs(k_size) - 1);
> + int k_size_base = 1 << (fls(k_size) - 1);
> int ret;
> void *block;
>
> block = memblock_alloc(k_size, k_size_base);
>
> if (block && k_size_base >= SZ_128K && k_start == ALIGN(k_start, k_size_base)) {
> - int shift = ffs(k_size - k_size_base);
> + int shift = fls(k_size - k_size_base);
> int k_size_more = shift ? 1 << (shift - 1) : 0;
>
> setbat(-1, k_start, __pa(block), k_size_base, PAGE_KERNEL);
>
>
>
Not sure it is that simple.
I'm cooking a patch reusing the block_size() function in mm/book3s32/mmu.c
Christophe
^ permalink raw reply
* Re: [PATCH] net: spider_net: Use non-atomic bitmap API when applicable
From: Geoff Levand @ 2021-12-04 15:47 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <3de0792f5088f00d135c835df6c19e63ae95f5d2.1638026251.git.christophe.jaillet@wanadoo.fr>
Hi Christophe,
On 11/27/21 7:18 AM, Christophe JAILLET wrote:
> No concurrent access is possible when a bitmap is local to a function.
> So prefer the non-atomic functions to save a few cycles.
> - replace a 'for' loop by an equivalent non-atomic 'bitmap_fill()' call
> - use '__set_bit()'
>
> While at it, clear the 'bitmask' bitmap only when needed.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This patch is *not* compile tested. I don't have the needed cross compiling
> tool chain.
> ---
> drivers/net/ethernet/toshiba/spider_net.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
As I mentioned, my tdd-builder Docker image has a
gcc-powerpc-linux-gnu cross compiler that can be used to build
a ppc64 kernel:
https://hub.docker.com/r/glevand/tdd-builder
I also have a few helper scripts to run the container and cross
compile a kernel:
https://github.com/glevand/tdd--docker/blob/master/builder/run-builder.sh
https://github.com/glevand/tdd-project/blob/master/scripts/build-linux-kernel.sh
I applied your patch to v5.16-rc3 and no spider_net warnings
or errors were seen when building with ppc64_defconfig. Thanks
for your contribution.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: Fail to boot 5.15 on mpc8347 with either debug_pagealloc or nobats
From: Christophe Leroy @ 2021-12-04 10:01 UTC (permalink / raw)
To: mbizon@freebox.fr, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <913068d2c368c80f89d6f9575d6b41e6fab48ae2.camel@freebox.fr>
Le 03/12/2021 à 19:43, Maxime Bizon a écrit :
>
> On Fri, 2021-12-03 at 12:49 +0000, Christophe Leroy wrote:
>
> Hello,
>
>> I need to think a bit more about it to find the cleanest solution
>> that works for all platforms.
>
> Maybe related, when enabling KASAN on that same platform, it oopses early.
Unrelated I think, but thanks for the report.
>
> I have picked the patch "powerpc/32s: Fix shift-out-of-bounds in KASAN
> init", and that does not fix it
>
>
> For some mem= values like 769M, all BATs are used for kernel linear
> mapping, and there are none left to map the KASAN shadow area in
> kasan/book3s_32.c => no oops
>
> If I don't compile kasan/book3s_32.c and use weak implementation => no
> oops
>
>
> But for mem=768M, it oopses
>
> I added some debugs in kasan init and dumped BATs content (BAT 7 is my
> debug BAT for uart)
>
> [ 0.000000] kasan_init_region: start=0xc0000000 size:0x30000000
> [ 0.000000] kasan_init_region: k_start:0xf8000000 k_end:0xfe000000 k_size:0x6000000 k_size_base=0x2000000
> [ 0.000000] kasan_init_region: IF{} k_size_more:0x4000000
> [ 0.000000] setbat index=3 virt:0xf8000000 phys:0x2a000000 size:0x2000000
> [ 0.000000] setbat index=4 virt:0xfa000000 phys:0x2c000000 size:0x4000000
> [ 0.000000] kasan_init_region: final k_cur=0xfe000000
> [ 0.000000]
> [ 0.000000] ---[ Data Block Address Translation ]---
> [ 0.000000] 0: 0xc0000000-0xcfffffff 0x00000000 256M Kernel rw m
> [ 0.000000] 1: 0xd0000000-0xdfffffff 0x10000000 256M Kernel rw m
> [ 0.000000] 2: 0xe0000000-0xefffffff 0x20000000 256M Kernel rw m
> [ 0.000000] 3: 0xf8000000-0xf9ffffff 0x2a000000 32M Kernel rw m
> [ 0.000000] 4: 0xfa000000-0xfdffffff 0x2c000000 64M Kernel rw m
> [ 0.000000] 5: -
> [ 0.000000] 6: -
> [ 0.000000] 7: 0xb0000000-0xb00fffff 0xe0000000 1M Kernel rw i g
> [ 0.000000] BUG: Unable to handle kernel data access on read at 0xfd3fce00
> [ 0.000000] Faulting instruction address: 0xc013ed84
> [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 0.000000] BE PAGE_SIZE=4K
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0+ #379
> [ 0.000000] NIP: c013ed84 LR: c0140264 CTR: 00000020
> [ 0.000000] REGS: c0b07dd0 TRAP: 0300 Not tainted (5.15.0+)
> [ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 28222448 XER: 00000000
> [ 0.000000] DAR: fd3fce00 DSISR: 20000000
> [ 0.000000] GPR00: fd3fd000 c0b07e80 c09c8a20 0000003f 00001000 00000001 c08c67a8 e9fe7fff
> [ 0.000000] GPR08: e9fe7000 fd3fce00 00000020 fd3fcfff 00000000 00000000 3ff9c5f0 3fffd79c
> [ 0.000000] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 0.000000] GPR24: 00000000 feffffff 00000591 c0b22000 ffffffff 00000000 e9fe7000 00001000
> [ 0.000000] NIP [c013ed84] kasan_check_range+0x98/0x2c0
> [ 0.000000] LR [c0140264] memset+0x34/0x80
> [ 0.000000] Call Trace:
> [ 0.000000] [c0b07e80] [c08c630c] memblock_alloc_internal+0x9c/0x108 (unreliable)
> [ 0.000000] [c0b07e90] [feffffff] 0xfeffffff
> [ 0.000000] [c0b07eb0] [c08c67a8] memblock_alloc_try_nid+0xf4/0x128
> [ 0.000000] [c0b07f30] [c08bb7ac] kasan_init_shadow_page_tables+0x84/0x1cc
> [ 0.000000] [c0b07f60] [c08bba40] kasan_init+0xdc/0x184
> [ 0.000000] [c0b07f90] [c08b8108] setup_arch+0x18/0x1c4
> [ 0.000000] [c0b07fc0] [c08b3fd4] start_kernel+0x5c/0x2d4
> [ 0.000000] [c0b07ff0] [000033c0] 0x33c0
> [ 0.000000] Instruction dump:
> [ 0.000000] 93e1000c 83c90000 83e90004 7fdffb79 83c10008 83e1000c 408201cc 2c030000
> [ 0.000000] 39290008 41820034 554af87e 7d4903a6 <80690000> 81490004 7c6a5379 408201a8
>
>
> It makes no sense to me that we get that fault with a valid BAT
> covering that area, BAT are not supposed to be checked first ?
>
In fact BAT4 is wrong. Both virtual and physical address of a 64M BAT
must be 64M aligned. I think the display is wrong as well (You took it
from ptdump ?), BEPI and BRPN must be anded with complement of BL.
So here your 64M BAT maps 0xf8000000-0xfbffffff, therefore the address
0xfd3fce00 is not mapped by any BAT hence the OOPS.
Christophe
^ permalink raw reply
* RE: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to unrecoverable loop.
From: Leo Li @ 2021-12-04 0:40 UTC (permalink / raw)
To: jocke@infinera.com, regressions@leemhuis.info,
Eugene_Bordenkircher@selinc.com, linux-usb@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Cc: gregkh@linuxfoundation.org, balbi@kernel.org
In-Reply-To: <f31008a0f4e71ff029aa611b0ebcfd83f10ec67f.camel@infinera.com>
> -----Original Message-----
> From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> Sent: Thursday, December 2, 2021 4:45 PM
> To: regressions@leemhuis.info; Leo Li <leoyang.li@nxp.com>;
> Eugene_Bordenkircher@selinc.com; linux-usb@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Cc: gregkh@linuxfoundation.org; balbi@kernel.org
> Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list leads to
> unrecoverable loop.
>
> On Thu, 2021-12-02 at 20:35 +0000, Leo Li wrote:
> >
> > > -----Original Message-----
> > > From: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
> > > Sent: Wednesday, December 1, 2021 8:19 AM
> > > To: regressions@leemhuis.info; Leo Li <leoyang.li@nxp.com>;
> > > Eugene_Bordenkircher@selinc.com; linux-usb@vger.kernel.org;
> > > linuxppc- dev@lists.ozlabs.org
> > > Cc: gregkh@linuxfoundation.org; balbi@kernel.org
> > > Subject: Re: bug: usb: gadget: FSL_UDC_CORE Corrupted request list
> > > leads to unrecoverable loop.
> > >
> > > On Tue, 2021-11-30 at 12:56 +0100, Joakim Tjernlund wrote:
> > > > On Mon, 2021-11-29 at 23:48 +0000, Eugene Bordenkircher wrote:
> > > > > Agreed,
> > > > >
> > > > > We are happy pick up the torch on this, but I'd like to try and
> > > > > hear from
> > > Joakim first before we do. The patch set is his, so I'd like to
> > > give him the opportunity. I think he's the only one that can add a
> > > truly proper description as well because he mentioned that this
> > > includes a "few more fixes" than just the one we ran into. I'd
> > > rather hear from him than try to reverse engineer what was being
> addressed.
> > > > >
> > > > > Joakim, if you are still watching the thread, would you like to
> > > > > take a stab
> > > at it? If I don't hear from you in a couple days, we'll pick up the
> > > torch and do what we can.
> > > > >
> > > >
> > > > I am far away from this now and still on 4.19. I don't mind if you
> > > > tweak
> > > tweak the patches for better "upstreamability"
> > >
> > > Even better would be to migrate to the chipidea driver, I am told
> > > just a few tweaks are needed but this is probably something NXP
> > > should do as they have access to other SOC's using chipidea.
> >
> > I agree with this direction but the problem was with bandwidth. As this
> controller was only used on legacy platforms, it is harder to justify new effort
> on it now.
> >
>
> Legacy? All PPC is legacy and not supported now?
I'm not saying that they are not supported, but they are in maintenance only mode.
Regards,
Leo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox