* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-26 9:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #38 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Looks like only x86 are arm implement this vmalloc= parameter:
[chleroy@PO20335 linux-powerpc]$ git grep 'early_param("vmalloc"' arch/
arch/arm/mm/mmu.c:early_param("vmalloc", early_vmalloc);
arch/x86/mm/pgtable_32.c:early_param("vmalloc", parse_vmalloc);
However, your vmalloc area has a size of 65M:
Kernel virtual memory layout:
* 0xf6000000..0xfec00000 : kasan shadow mem
* 0xf5bbf000..0xf5fff000 : fixmap
* 0xf5400000..0xf5800000 : highmem PTEs
* 0xf5115000..0xf5400000 : early ioremap
* 0xf1000000..0xf5110000 : vmalloc & ioremap
* 0xb0000000..0xc0000000 : modules
Memory: 1928984K/2097152K available (22288K kernel code, 2616K rwdata, 4868K
rodata, 1408K init, 8981K bss, 168168K reserved, 0K cma-reserved, 1310720K
highmem)
--
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 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-26 9:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #37 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
I see no obvious reason for a 32Mb allocation to fail while you have 588612kB
free memory.
And that happens early at boot, before user processes are started so the vmap
area, allthough not very big, should still have 32M space available.
--
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: [PATCH] powerpc/code-patching: Relax verification of patchability
From: Christophe Leroy @ 2021-11-26 8:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Sachin Sant, Stephen Rothwell, linuxppc-dev, linux-kernel,
Nicholas Piggin
In-Reply-To: <68d7d57675e0963fe5e2c4b84b0cb2390c78638c.1637912333.git.christophe.leroy@csgroup.eu>
Le 26/11/2021 à 08:39, Christophe Leroy a écrit :
> Commit 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of
> patchability") introduced a stricter verification of the patched
> area by checking it is proper kernel text.
>
> But as least two usages of patch_instruction() fall outside:
> - Code patching selftests, which use stack and vmalloc space.
> - Ftrace
>
> So for the time being, partially revert commit 8b8a8f0ab3f5 and add
> a onetime warning:
>
> Running code patching self-tests ...
> patch_instruction() called on invalid text address 0xe1011e58 from test_code_patching+0x34/0xd6c
>
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Fixes: 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of patchability")
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/lib/code-patching.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index 1dd636a85cc1..c87eea773930 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -190,9 +190,13 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
> int patch_instruction(u32 *addr, struct ppc_inst instr)
> {
> /* Make sure we aren't patching a freed init section */
> - if (!kernel_text_address((unsigned long)addr))
> + if (system_state >= SYSTEM_FREEING_INITMEM && init_section_contains(addr, 4))
> return 0;
>
> + if (!kernel_text_address((unsigned long)addr))
> + pr_warn_once("%s() called on invalid text address 0x%p from %pS\n",
> + __func__, addr, __builtin_return_address(0));
> +
May it be better to use pr_warn_ratelimited() instead in order to catch
more than the first occurence ?
> return do_patch_instruction(addr, instr);
> }
> NOKPROBE_SYMBOL(patch_instruction);
>
^ permalink raw reply
* Re: [PATCH] recordmcount: Support empty section from recent binutils
From: LEROY Christophe @ 2021-11-26 8:43 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Steven Rostedt
In-Reply-To: <cd0f6bdfdf1ee096fb2c07e7b38940921b8e9118.1637764848.git.christophe.leroy@csgroup.eu>
Le 24/11/2021 à 15:43, Christophe Leroy a écrit :
> Looks like recent binutils (2.36 and over ?) may empty some section,
> leading to failure like:
>
> Cannot find symbol for section 11: .text.unlikely.
> kernel/kexec_file.o: failed
> make[1]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1
>
> In order to avoid that, ensure that the section has a content before
> returning it's name in has_rel_mcount().
This patch doesn't work, on PPC32 I get the following message with this
patch applied:
[ 0.000000] ftrace: No functions to be traced?
Without the patch I get:
[ 0.000000] ftrace: allocating 22381 entries in 66 pages
[ 0.000000] ftrace: allocated 66 pages with 2 groups
Christophe
>
> Suggested-by: Steven Rostedt <rostedt@goodmis.org>
> Link: https://github.com/linuxppc/issues/issues/388
> Link: https://lore.kernel.org/all/20210215162209.5e2a475b@gandalf.local.home/
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> scripts/recordmcount.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 1e9baa5c4fc6..cc6600b729ae 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -575,6 +575,8 @@ static char const *has_rel_mcount(Elf_Shdr const *const relhdr,
> char const *const shstrtab,
> char const *const fname)
> {
> + if (!shdr0->sh_size)
> + return NULL;
> if (w(relhdr->sh_type) != SHT_REL && w(relhdr->sh_type) != SHT_RELA)
> return NULL;
> return __has_rel_mcount(relhdr, shdr0, shstrtab, fname);
>
^ permalink raw reply
* [PATCH] powerpc/code-patching: Relax verification of patchability
From: Christophe Leroy @ 2021-11-26 7:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Sachin Sant, Stephen Rothwell, linux-kernel, Nicholas Piggin,
linuxppc-dev
Commit 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of
patchability") introduced a stricter verification of the patched
area by checking it is proper kernel text.
But as least two usages of patch_instruction() fall outside:
- Code patching selftests, which use stack and vmalloc space.
- Ftrace
So for the time being, partially revert commit 8b8a8f0ab3f5 and add
a onetime warning:
Running code patching self-tests ...
patch_instruction() called on invalid text address 0xe1011e58 from test_code_patching+0x34/0xd6c
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Fixes: 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of patchability")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/lib/code-patching.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 1dd636a85cc1..c87eea773930 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -190,9 +190,13 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
int patch_instruction(u32 *addr, struct ppc_inst instr)
{
/* Make sure we aren't patching a freed init section */
- if (!kernel_text_address((unsigned long)addr))
+ if (system_state >= SYSTEM_FREEING_INITMEM && init_section_contains(addr, 4))
return 0;
+ if (!kernel_text_address((unsigned long)addr))
+ pr_warn_once("%s() called on invalid text address 0x%p from %pS\n",
+ __func__, addr, __builtin_return_address(0));
+
return do_patch_instruction(addr, instr);
}
NOKPROBE_SYMBOL(patch_instruction);
--
2.33.1
^ permalink raw reply related
* Re: [PATCH v4 00/17] powerpc: Make hash MMU code build configurable
From: Christophe Leroy @ 2021-11-26 7:20 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1637887917.uatiybce4e.astroid@bobo.none>
Le 26/11/2021 à 01:55, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of November 26, 2021 3:35 am:
>>
>>
>> Le 25/11/2021 à 17:35, Christophe Leroy a écrit :
>>>
>>>
>>> Le 25/11/2021 à 13:50, Nicholas Piggin a écrit :
>>>> Now that there's a platform that can make good use of it, here's
>>>> a series that can prevent the hash MMU code being built for 64s
>>>> platforms that don't need it.
>>>
>>> # CONFIG_PPC_64S_HASH_MMU is not set
>>>
>>>
>>> <stdin>:1559:2: warning: #warning syscall futex_waitv not implemented
>>> [-Wcpp]
>>> arch/powerpc/platforms/cell/spu_base.c: In function '__spu_kernel_slb':
>>> arch/powerpc/platforms/cell/spu_base.c:215:38: error: 'mmu_linear_psize'
>>> undeclared (first use in this function); did you mean 'mmu_virtual_psize'?
>>> 215 | llp = mmu_psize_defs[mmu_linear_psize].sllp;
>>> | ^~~~~~~~~~~~~~~~
>>> | mmu_virtual_psize
>>> arch/powerpc/platforms/cell/spu_base.c:215:38: note: each undeclared
>>> identifier is reported only once for each function it appears in
>>> make[3]: *** [scripts/Makefile.build:287:
>>> arch/powerpc/platforms/cell/spu_base.o] Error 1
>>> make[2]: *** [scripts/Makefile.build:549: arch/powerpc/platforms/cell]
>>> Error 2
>>> make[1]: *** [scripts/Makefile.build:549: arch/powerpc/platforms] Error 2
>>> make: *** [Makefile:1846: arch/powerpc] Error 2
>>>
>>>
>>
>>
>> With CONFIG_SPU_BASE removed, the above voids and I get to the final
>> link with the following errors:
>
> This is building cell platform with POWER9 CPU and !HASH?
I took ppc64_defconfig, changed CPU to POWER9 and removed VIRTUALIZATION
and removed CONFIG_PPC_64S_HASH_MMU.
>
> We don't have to make that build, just prevent the config. I had that in
> a previous version which also had platforms select hash, but we went to
> just CPU. But now there's no constraint that prevents cell+POWER9 even
> though it doesn't make sense.
>
> Not sure the best way to fix it. I'll think about it.
>
Force selection of CONFIG_PPC_64S_HASH_MMU by the CELL platform ?
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/vas: Don't print an error when VAS is unavailable
From: Cédric Le Goater @ 2021-11-26 7:13 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Haren Myneni
In-Reply-To: <20211126052133.1664375-1-npiggin@gmail.com>
On 11/26/21 06:21, Nicholas Piggin wrote:
> KVM does not support VAS so guests always print a useless error on boot
>
> vas: HCALL(398) error -2, query_type 0, result buffer 0x57f2000
>
> Change this to only print the message if the error is not H_FUNCTION.
Just being curious, why is it even called since "ibm,compression" should
not be exposed in the DT ?
C.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/platforms/pseries/vas.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c
> index b043e3936d21..734523e2272f 100644
> --- a/arch/powerpc/platforms/pseries/vas.c
> +++ b/arch/powerpc/platforms/pseries/vas.c
> @@ -151,8 +151,15 @@ int h_query_vas_capabilities(const u64 hcall, u8 query_type, u64 result)
> if (rc == H_SUCCESS)
> return 0;
>
> - pr_err("HCALL(%llx) error %ld, query_type %u, result buffer 0x%llx\n",
> - hcall, rc, query_type, result);
> + /* H_FUNCTION means HV does not support VAS so don't print an error */
> + if (rc != H_FUNCTION) {
> + pr_err("%s error %ld, query_type %u, result buffer 0x%llx\n",
> + (hcall == H_QUERY_VAS_CAPABILITIES) ?
> + "H_QUERY_VAS_CAPABILITIES" :
> + "H_QUERY_NX_CAPABILITIES",
> + rc, query_type, result);
> + }
> +
> return -EIO;
> }
> EXPORT_SYMBOL_GPL(h_query_vas_capabilities);
>
^ permalink raw reply
* [powerpc/merge] ftrace warning while running stress_code_patching
From: Sachin Sant @ 2021-11-26 6:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
While running stress_code_patching.sh (powerpc/mm selftest) against
latest powerpc/merge branch (5.16.0-rc2-g2dbc3a3e8fc1) following
warning is seen:
Reverting following patch allows the test to run successfully.
commit 8b8a8f0ab3f5 :
powerpc/code-patching: Improve verification of patchability
I did try the 3 patch series [1] (powerpc/code-patching) posted by Nick, but that does not
seem to fix the problem.
ftrace-powerpc: Unexpected call sequence at 000000001d3f5e8d: 4801c5ad 2c230000
------------[ ftrace bug ]------------
ftrace failed to modify
[<c008000007110004>] fuse_len_args+0x4/0x80 [fuse]
actual: ad:c5:01:48
Setting ftrace call site to call ftrace function
ftrace record flags: 80000001
(1)
expected tramp: c000000000082494
------------[ cut here ]------------
WARNING: CPU: 18 PID: 1991307 at kernel/trace/ftrace.c:2068 ftrace_bug+0x274/0x2e8
Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill libcrc32c nfnetlink sunrpc pseries_rng xts vmx_crypto sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse
CPU: 18 PID: 1991307 Comm: stress_code_pat Not tainted 5.16.0-rc2-g2dbc3a3e8fc1 #1
NIP: c0000000002d710c LR: c0000000002d7108 CTR: c0000000001f5e40
REGS: c000000039d9b760 TRAP: 0700 Not tainted (5.16.0-rc2-g2dbc3a3e8fc1)
MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48228224 XER: 20040009
CFAR: c0000000001f99e0 IRQMASK: 0
GPR00: c0000000002d7108 c000000039d9ba00 c000000002a00500 0000000000000022
GPR04: 00000000ffff7fff c000000039d9b720 0000000000000027 c000000efd747e18
GPR08: 0000000000000023 0000000000000001 0000000000000027 0000000000000001
GPR12: 0000000000008000 c000000effbf8280 0000000040000000 000000012d9f9798
GPR16: 000000012d9f9724 000000012d996be8 000000012d92f4f0 000000012d9fd568
GPR20: 000000015bed3ed0 0000000000000001 000000012d9a99d8 00007fffc36f7f54
GPR24: 0000000000000001 0000000000000000 c000000039d9bc70 c000000000faf228
GPR28: c000000000ff3730 c000000000fac298 c008000007110004 c000000016690000
NIP [c0000000002d710c] ftrace_bug+0x274/0x2e8
LR [c0000000002d7108] ftrace_bug+0x270/0x2e8
Call Trace:
[c000000039d9ba00] [c0000000002d7108] ftrace_bug+0x270/0x2e8 (unreliable)
[c000000039d9ba90] [c0000000002d05c8] ftrace_modify_all_code+0x108/0x1c0
[c000000039d9bac0] [c0000000000822b8] arch_ftrace_update_code+0x18/0x30
[c000000039d9bae0] [c0000000002d07b8] ftrace_run_update_code+0x58/0xe0
[c000000039d9bb10] [c0000000002d5a78] ftrace_startup+0xf8/0x1a0
[c000000039d9bb50] [c0000000002d5b6c] register_ftrace_function+0x4c/0xc0
[c000000039d9bb80] [c0000000002f9b38] function_trace_init+0x88/0x100
[c000000039d9bbb0] [c0000000002efaf8] tracing_set_tracer+0x368/0x550
[c000000039d9bc50] [c0000000002efdf8] tracing_set_trace_write+0x118/0x180
[c000000039d9bd10] [c000000000491e50] vfs_write+0xf0/0x340
[c000000039d9bd60] [c00000000049227c] ksys_write+0x7c/0x140
[c000000039d9bdb0] [c000000000033284] system_call_exception+0x174/0x370
[c000000039d9be10] [c00000000000c74c] system_call_common+0xec/0x250
--- interrupt: c00 at 0x7fffb4f0bd74
NIP: 00007fffb4f0bd74 LR: 00007fffb4e834c4 CTR: 0000000000000000
REGS: c000000039d9be80 TRAP: 0c00 Not tainted (5.16.0-rc2-g2dbc3a3e8fc1)
MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28222222 XER: 00000000
IRQMASK: 0
GPR00: 0000000000000004 00007fffc36f7d30 00007fffb5007100 0000000000000001
GPR04: 000000015bed1750 0000000000000009 0000000000000010 000000006e6f6974
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00007fffb513aeb0 0000000040000000 000000012d9f9798
GPR16: 000000012d9f9724 000000012d996be8 000000012d92f4f0 000000012d9fd568
GPR20: 000000015bed3ed0 0000000000000001 000000012d9a99d8 00007fffc36f7f54
GPR24: 00007fffc36f7f50 000000012d9faf94 0000000000000009 000000015bed1750
GPR28: 0000000000000009 00007fffb5001848 000000015bed1750 0000000000000009
NIP [00007fffb4f0bd74] 0x7fffb4f0bd74
LR [00007fffb4e834c4] 0x7fffb4e834c4
--- interrupt: c00
Instruction dump:
48000014 3c62fe5f 386333e0 4bf228b1 60000000 7fe3fb78 4bff88c5 7c641b78
3c62fe5f 386333f8 4bf22895 60000000 <0fe00000> 38210090 39000001 3d22fd68
---[ end trace c4abf5aea4841297 ]---
Thanks
-Sachin
[1] https://lore.kernel.org/linuxppc-dev/f9e53405-b5b9-15d1-eaf9-0616a5b87424@csgroup.eu/T/
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/code-patching: work around code patching verification in patching tests
From: Christophe Leroy @ 2021-11-26 6:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20211126032249.1652080-1-npiggin@gmail.com>
Le 26/11/2021 à 04:22, Nicholas Piggin a écrit :
> Code patching tests patch the stack and (non-module) vmalloc space now,
> which falls afoul of the new address check.
>
> The stack patching can easily be fixed, but the vmalloc patching is more
> difficult. For now, add an ugly workaround to skip the check while the
> test code is running.
This really looks hacky.
To skip the test, you can call do_patch_instruction() instead of calling
patch_instruction().
>
> Fixes: 8b8a8f0ab3f55 ("powerpc/code-patching: Improve verification of patchability")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/lib/code-patching.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index 5e2fe133639e..57e160963ab7 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -187,10 +187,12 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
>
> #endif /* CONFIG_STRICT_KERNEL_RWX */
>
> +static bool skip_addr_verif = false;
> +
> int patch_instruction(u32 *addr, struct ppc_inst instr)
> {
> /* Make sure we aren't patching a freed init section */
> - if (!kernel_text_address((unsigned long)addr))
> + if (!skip_addr_verif && !kernel_text_address((unsigned long)addr))
> return 0;
>
> return do_patch_instruction(addr, instr);
> @@ -738,11 +740,13 @@ static int __init test_code_patching(void)
> {
> printk(KERN_DEBUG "Running code patching self-tests ...\n");
>
> + skip_addr_verif = true;
> test_branch_iform();
> test_branch_bform();
> test_create_function_call();
> test_translate_branch();
> test_prefixed_patching();
> + skip_addr_verif = false;
>
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH] powerpc/64s/radix: Fix unmapping huge vmaps when CONFIG_HUGETLB_PAGE=n
From: Daniel Axtens @ 2021-11-26 6:09 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211126022834.1622106-1-npiggin@gmail.com>
Hi,
> pmd_huge is defined out to false when HUGETLB_PAGE is not configured,
> but the vmap code still installs huge PMDs. This leads to errors
> encountering bad PMDs when vunmapping because it is not seen as a
> huge PTE, and the bad PMD check catches it. The end result may not
> be much more serious than some bad pmd warning messages, because the
> pmd_none_or_clear_bad() does what we wanted and clears the huge PTE
> anyway.
Huh. So vmap seems to key off arch_vmap_p?d_supported which checks for
radix and HAVE_ARCH_HUGE_VMAP.
> Fix this by checking pmd_is_leaf(), which checks for a PTE regardless
> of config options. The whole huge/large/leaf stuff is a tangled mess
> but that's kernel-wide and not something we can improve much in
> arch/powerpc code.
I guess I'm a bit late to the party here because p?d_is_leaf was added
in 2019 in commit d6eacedd1f0e ("powerpc/book3s: Use config independent
helpers for page table walk") but why wouldn't we just make pmd_huge()
not config dependent?
Also, looking at that commit, there are a few places that might still
throw warnings, e.g. find_linux_pte, find_current_mm_pte, pud_page which
seem like they might still throw warnings if they were to encounter a
huge vmap page:
struct page *pud_page(pud_t pud)
{
if (pud_is_leaf(pud)) {
VM_WARN_ON(!pud_huge(pud));
Do these functions need special treatment for huge vmappings()?
Apart from those questions, the patch itself makes sense to me and I can
follow how it would fix a problem.
Reviewed-by: Daniel Axtens <dja@axtens.net>
Kind regards,
Daniel
^ permalink raw reply
* Re: linux-next: runtime warnings from qemu run
From: Christophe Leroy @ 2021-11-26 5:48 UTC (permalink / raw)
To: Stephen Rothwell, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20211126161747.1f7795b0@canb.auug.org.au>
Le 26/11/2021 à 06:17, Stephen Rothwell a écrit :
> Hi all,
>
> My qemu boot test (pseries_le_defconfig) produces these new messages:
>
> code-patching: test failed at line 444
> code-patching: test failed at line 447
> code-patching: test failed at line 450
> code-patching: test failed at line 453
> code-patching: test failed at line 456
> code-patching: test failed at line 461
> code-patching: test failed at line 466
> code-patching: test failed at line 471
> code-patching: test failed at line 476
> code-patching: test failed at line 493
> code-patching: test failed at line 533
> code-patching: test failed at line 536
> code-patching: test failed at line 539
> code-patching: test failed at line 542
> code-patching: test failed at line 545
> code-patching: test failed at line 553
> code-patching: test failed at line 558
> code-patching: test failed at line 563
> code-patching: test failed at line 568
> code-patching: test failed at line 585
> code-patching: test failed at line 605
> code-patching: test failed at line 609
> code-patching: test failed at line 618
> code-patching: test failed at line 619
> code-patching: test failed at line 620
> code-patching: test failed at line 629
> code-patching: test failed at line 630
> code-patching: test failed at line 631
> code-patching: test failed at line 640
> code-patching: test failed at line 641
> code-patching: test failed at line 650
> code-patching: test failed at line 651
> code-patching: test failed at line 661
> code-patching: test failed at line 665
> code-patching: test failed at line 675
> code-patching: test failed at line 676
> code-patching: test failed at line 677
> code-patching: test failed at line 687
> code-patching: test failed at line 688
> code-patching: test failed at line 689
> code-patching: test failed at line 699
> code-patching: test failed at line 700
> code-patching: test failed at line 710
> code-patching: test failed at line 711
>
> Maybe caused by commit
>
> 8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of patchability")
Yes, Nic proposed a series to fix that:
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211126032249.1652080-1-npiggin@gmail.com/
>
> As an presumably unrelated aside, we seem to be using a bit more stack
> space as well
>
> - mount (54) used greatest stack depth: 12512 bytes left
> - mount (55) used greatest stack depth: 12032 bytes left
> + mount (54) used greatest stack depth: 10608 bytes left
>
^ permalink raw reply
* [PATCH] powerpc/pseries/vas: Don't print an error when VAS is unavailable
From: Nicholas Piggin @ 2021-11-26 5:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Haren Myneni, Nicholas Piggin
KVM does not support VAS so guests always print a useless error on boot
vas: HCALL(398) error -2, query_type 0, result buffer 0x57f2000
Change this to only print the message if the error is not H_FUNCTION.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/platforms/pseries/vas.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c
index b043e3936d21..734523e2272f 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -151,8 +151,15 @@ int h_query_vas_capabilities(const u64 hcall, u8 query_type, u64 result)
if (rc == H_SUCCESS)
return 0;
- pr_err("HCALL(%llx) error %ld, query_type %u, result buffer 0x%llx\n",
- hcall, rc, query_type, result);
+ /* H_FUNCTION means HV does not support VAS so don't print an error */
+ if (rc != H_FUNCTION) {
+ pr_err("%s error %ld, query_type %u, result buffer 0x%llx\n",
+ (hcall == H_QUERY_VAS_CAPABILITIES) ?
+ "H_QUERY_VAS_CAPABILITIES" :
+ "H_QUERY_NX_CAPABILITIES",
+ rc, query_type, result);
+ }
+
return -EIO;
}
EXPORT_SYMBOL_GPL(h_query_vas_capabilities);
--
2.23.0
^ permalink raw reply related
* linux-next: runtime warnings from qemu run
From: Stephen Rothwell @ 2021-11-26 5:17 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]
Hi all,
My qemu boot test (pseries_le_defconfig) produces these new messages:
code-patching: test failed at line 444
code-patching: test failed at line 447
code-patching: test failed at line 450
code-patching: test failed at line 453
code-patching: test failed at line 456
code-patching: test failed at line 461
code-patching: test failed at line 466
code-patching: test failed at line 471
code-patching: test failed at line 476
code-patching: test failed at line 493
code-patching: test failed at line 533
code-patching: test failed at line 536
code-patching: test failed at line 539
code-patching: test failed at line 542
code-patching: test failed at line 545
code-patching: test failed at line 553
code-patching: test failed at line 558
code-patching: test failed at line 563
code-patching: test failed at line 568
code-patching: test failed at line 585
code-patching: test failed at line 605
code-patching: test failed at line 609
code-patching: test failed at line 618
code-patching: test failed at line 619
code-patching: test failed at line 620
code-patching: test failed at line 629
code-patching: test failed at line 630
code-patching: test failed at line 631
code-patching: test failed at line 640
code-patching: test failed at line 641
code-patching: test failed at line 650
code-patching: test failed at line 651
code-patching: test failed at line 661
code-patching: test failed at line 665
code-patching: test failed at line 675
code-patching: test failed at line 676
code-patching: test failed at line 677
code-patching: test failed at line 687
code-patching: test failed at line 688
code-patching: test failed at line 689
code-patching: test failed at line 699
code-patching: test failed at line 700
code-patching: test failed at line 710
code-patching: test failed at line 711
Maybe caused by commit
8b8a8f0ab3f5 ("powerpc/code-patching: Improve verification of patchability")
As an presumably unrelated aside, we seem to be using a bit more stack
space as well
- mount (54) used greatest stack depth: 12512 bytes left
- mount (55) used greatest stack depth: 12032 bytes left
+ mount (54) used greatest stack depth: 10608 bytes left
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [kbuild-all] Re: [PATCH 1/8] powerpc/mm: Make slice specific to book3s/64
From: Chen, Rong A @ 2021-11-26 5:15 UTC (permalink / raw)
To: Christophe Leroy, kernel test robot, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, alex
Cc: linux-mm, kbuild-all, linuxppc-dev, linux-kernel
In-Reply-To: <da5038fd-611a-a0b3-10b7-35dac6817e6a@csgroup.eu>
On 11/24/2021 9:49 PM, Christophe Leroy wrote:
>
>
> Le 24/11/2021 à 13:10, Christophe Leroy a écrit :
>>
>>
>> Le 22/11/2021 à 15:48, kernel test robot a écrit :
>>> Hi Christophe,
>>>
>>> I love your patch! Perhaps something to improve:
>>>
>>> [auto build test WARNING on powerpc/next]
>>> [also build test WARNING on hnaz-mm/master linus/master v5.16-rc2
>>> next-20211118]
>>> [If your patch is applied to the wrong git tree, kindly drop us a note.
>>> And when submitting patch, we suggest to use '--base' as documented in
>>> https://git-scm.com/docs/git-format-patch]
>>>
>>> url:
>>> https://github.com/0day-ci/linux/commits/Christophe-Leroy/Convert-powerpc-to-default-topdown-mmap-layout/20211122-165115
>>>
>>> base:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
>>> config: powerpc64-randconfig-s031-20211122 (attached as .config)
>>> compiler: powerpc64-linux-gcc (GCC) 11.2.0
>>> reproduce:
>>> wget
>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
>>> -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # apt-get install sparse
>>> # sparse version: v0.6.4-dirty
>>> #
>>> https://github.com/0day-ci/linux/commit/1d0b7cc86d08f25f595b52d8c39ba9ca1d29a30a
>>>
>>> git remote add linux-review https://github.com/0day-ci/linux
>>> git fetch --no-tags linux-review
>>> Christophe-Leroy/Convert-powerpc-to-default-topdown-mmap-layout/20211122-165115
>>>
>>> git checkout 1d0b7cc86d08f25f595b52d8c39ba9ca1d29a30a
>>> # save the attached .config to linux build tree
>>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0
>>> make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>>> ARCH=powerpc64
>>>
>>> If you fix the issue, kindly add following tag as appropriate
>>> Reported-by: kernel test robot <lkp@intel.com>
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>> arch/powerpc/mm/book3s64/slice.c: In function
>>> 'slice_get_unmapped_area':
>>>>> arch/powerpc/mm/book3s64/slice.c:639:1: warning: the frame size of
>>>>> 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>> 639 | }
>>> | ^
>>
>>
>> The problem was already existing when slice.c was in arch/powerpc/mm/
>>
>> This patch doesn't introduce the problem.
>>
>
> In fact the problem is really added by yourself mister 'kernel test robot'.
>
> CONFIG_FRAME_WARN is supposed to be 2048 on 64 bit architectures.
>
> It the robot starts to reduce that value, it is on its own ....
Hi Christophe,
Thanks for the information, we'll set the default value for FRAME_WARN
in randconfig tests.
Best Regards,
Rong Chen
>
>
> config FRAME_WARN
> int "Warn for stack frames larger than"
> range 0 8192
> default 2048 if GCC_PLUGIN_LATENT_ENTROPY
> default 1536 if (!64BIT && (PARISC || XTENSA))
> default 1024 if (!64BIT && !PARISC)
> default 2048 if 64BIT
> help
> Tell gcc to warn at build time for stack frames larger than this.
> Setting this too low will cause a lot of warnings.
> Setting it to 0 disables the warning.
> _______________________________________________
> kbuild-all mailing list -- kbuild-all@lists.01.org
> To unsubscribe send an email to kbuild-all-leave@lists.01.org
^ permalink raw reply
* [PATCH] powerpc/85xx: fix oops when CONFIG_FSL_PMC=n
From: Xiaoming Ni @ 2021-11-26 4:11 UTC (permalink / raw)
To: hurricos, Yuantian.Tang, benh, chenhui.zhao, chenjianguo3, gregkh,
linux-kernel, linuxppc-dev, liuwenliang, mpe, oss, paul.gortmaker,
paulus, stable, wangle6, chunkeey
Cc: nixiaoming
In-Reply-To: <5f56f1af-9404-21fa-eda0-05a75d769427@huawei.com>
When CONFIG_FSL_PMC is set to n, no value is assigned to cpu_up_prepare
in the mpc85xx_pm_ops structure. As a result, oops is triggered in
smp_85xx_start_cpu().
[ 0.627233] smp: Bringing up secondary CPUs ...
[ 0.681659] kernel tried to execute user page (0) - exploit attempt? (uid: 0)
[ 0.766618] BUG: Unable to handle kernel instruction fetch (NULL pointer?)
[ 0.848899] Faulting instruction address: 0x00000000
[ 0.908273] Oops: Kernel access of bad area, sig: 11 [#1]
...
[ 1.758220] NIP [00000000] 0x0
[ 1.794688] LR [c0021d2c] smp_85xx_kick_cpu+0xe8/0x568
[ 1.856126] Call Trace:
[ 1.885295] [c1051da8] [c0021cb8] smp_85xx_kick_cpu+0x74/0x568 (unreliable)
[ 1.968633] [c1051de8] [c0011460] __cpu_up+0xc0/0x228
[ 2.029038] [c1051e18] [c0031bbc] bringup_cpu+0x30/0x224
[ 2.092572] [c1051e48] [c0031f3c] cpu_up.constprop.0+0x180/0x33c
[ 2.164443] [c1051e88] [c00322e8] bringup_nonboot_cpus+0x88/0xc8
[ 2.236326] [c1051eb8] [c07e67bc] smp_init+0x30/0x78
[ 2.295698] [c1051ed8] [c07d9e28] kernel_init_freeable+0x118/0x2a8
[ 2.369641] [c1051f18] [c00032d8] kernel_init+0x14/0x124
[ 2.433176] [c1051f38] [c0010278] ret_from_kernel_thread+0x14/0x1c
Fixes: c45361abb9185b ("powerpc/85xx: fix timebase sync issue when
CONFIG_HOTPLUG_CPU=n")
Link: https://lore.kernel.org/lkml/CANA18Uyba4kMJQrbCSZVTFep2Exe5izE45whNJgwwUvNSEcNLg@mail.gmail.com/
Reported-by: Martin Kennedy <hurricos@gmail.com>
Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
Tested-by: Martin Kennedy <hurricos@gmail.com>
Cc: stable@vger.kernel.org
---
arch/powerpc/platforms/85xx/smp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 83f4a6389a28..d7081e9af65c 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -220,7 +220,7 @@ static int smp_85xx_start_cpu(int cpu)
local_irq_save(flags);
hard_irq_disable();
- if (qoriq_pm_ops)
+ if (qoriq_pm_ops && qoriq_pm_ops->cpu_up_prepare)
qoriq_pm_ops->cpu_up_prepare(cpu);
/* if cpu is not spinning, reset it */
@@ -292,7 +292,7 @@ static int smp_85xx_kick_cpu(int nr)
booting_thread_hwid = cpu_thread_in_core(nr);
primary = cpu_first_thread_sibling(nr);
- if (qoriq_pm_ops)
+ if (qoriq_pm_ops && qoriq_pm_ops->cpu_up_prepare)
qoriq_pm_ops->cpu_up_prepare(nr);
/*
--
2.27.0
^ permalink raw reply related
* [PATCH 3/3] powerpc/code-patching: don't use the stack for code patching tests
From: Nicholas Piggin @ 2021-11-26 3:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211126032249.1652080-1-npiggin@gmail.com>
Use the existing test function for code patching tests instead of
writing to the stack. This means the address verification does not have
to be bypassed for these tests.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/lib/code-patching.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 70247fc58b6e..babf6b22adef 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -422,9 +422,11 @@ static void __init test_branch_iform(void)
{
int err;
struct ppc_inst instr;
- u32 tmp[2];
- u32 *iptr = tmp;
- unsigned long addr = (unsigned long)tmp;
+ u32 *iptr;
+ unsigned long addr;
+
+ iptr = (u32 *)ppc_function_entry(test_trampoline);
+ addr = (unsigned long)iptr;
/* The simplest case, branch to self, no flags */
check(instr_is_branch_iform(ppc_inst(0x48000000)));
@@ -516,12 +518,12 @@ static void __init test_create_function_call(void)
static void __init test_branch_bform(void)
{
int err;
- unsigned long addr;
struct ppc_inst instr;
- u32 tmp[2];
- u32 *iptr = tmp;
+ u32 *iptr;
+ unsigned long addr;
unsigned int flags;
+ iptr = (u32 *)ppc_function_entry(test_trampoline);
addr = (unsigned long)iptr;
/* The simplest case, branch to self, no flags */
@@ -603,6 +605,12 @@ static void __init test_translate_branch(void)
if (!buf)
return;
+ /*
+ * Have to disable the address bounds check for patch_instruction
+ * because we are patching vmalloc space here.
+ */
+ skip_addr_verif = true;
+
/* Simple case, branch to self moved a little */
p = buf;
addr = (unsigned long)p;
@@ -715,6 +723,8 @@ static void __init test_translate_branch(void)
check(instr_is_branch_to_addr(p, addr));
check(instr_is_branch_to_addr(q, addr));
+ skip_addr_verif = false;
+
/* Free the buffer we were using */
vfree(buf);
}
@@ -743,13 +753,11 @@ static int __init test_code_patching(void)
{
printk(KERN_DEBUG "Running code patching self-tests ...\n");
- skip_addr_verif = true;
test_branch_iform();
test_branch_bform();
test_create_function_call();
test_translate_branch();
test_prefixed_patching();
- skip_addr_verif = false;
return 0;
}
--
2.23.0
^ permalink raw reply related
* [PATCH 2/3] powerpc/code-patching: warn on code patching failure
From: Nicholas Piggin @ 2021-11-26 3:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20211126032249.1652080-1-npiggin@gmail.com>
Callers are supposed to handle this, but it is possible that they
don't or they do but don't make much noise about it. A failure is
probably an indication of a bigger problem somewhere so it is good
to warn once about it.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/lib/code-patching.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 57e160963ab7..70247fc58b6e 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -161,6 +161,7 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
text_poke_addr = (unsigned long)__this_cpu_read(text_poke_area)->addr;
if (map_patch_area(addr, text_poke_addr)) {
+ WARN_ON_ONCE(1);
err = -1;
goto out;
}
@@ -192,8 +193,10 @@ static bool skip_addr_verif = false;
int patch_instruction(u32 *addr, struct ppc_inst instr)
{
/* Make sure we aren't patching a freed init section */
- if (!skip_addr_verif && !kernel_text_address((unsigned long)addr))
+ if (!skip_addr_verif && !kernel_text_address((unsigned long)addr)) {
+ WARN_ON_ONCE(1);
return 0;
+ }
return do_patch_instruction(addr, instr);
}
--
2.23.0
^ permalink raw reply related
* [PATCH 1/3] powerpc/code-patching: work around code patching verification in patching tests
From: Nicholas Piggin @ 2021-11-26 3:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
Code patching tests patch the stack and (non-module) vmalloc space now,
which falls afoul of the new address check.
The stack patching can easily be fixed, but the vmalloc patching is more
difficult. For now, add an ugly workaround to skip the check while the
test code is running.
Fixes: 8b8a8f0ab3f55 ("powerpc/code-patching: Improve verification of patchability")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/lib/code-patching.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 5e2fe133639e..57e160963ab7 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -187,10 +187,12 @@ static int do_patch_instruction(u32 *addr, struct ppc_inst instr)
#endif /* CONFIG_STRICT_KERNEL_RWX */
+static bool skip_addr_verif = false;
+
int patch_instruction(u32 *addr, struct ppc_inst instr)
{
/* Make sure we aren't patching a freed init section */
- if (!kernel_text_address((unsigned long)addr))
+ if (!skip_addr_verif && !kernel_text_address((unsigned long)addr))
return 0;
return do_patch_instruction(addr, instr);
@@ -738,11 +740,13 @@ static int __init test_code_patching(void)
{
printk(KERN_DEBUG "Running code patching self-tests ...\n");
+ skip_addr_verif = true;
test_branch_iform();
test_branch_bform();
test_create_function_call();
test_translate_branch();
test_prefixed_patching();
+ skip_addr_verif = false;
return 0;
}
--
2.23.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.10 03/28] powerpc/pseries/ddw: Revert "Extend upper limit for huge DMA window for persistent memory"
From: Sasha Levin @ 2021-11-26 2:33 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, leobras.c, Alexey Kardashevskiy, fbarrat,
linuxppc-dev
In-Reply-To: <20211126023343.442045-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit 2d33f5504490a9d90924476dbccd4a5349ee1ad0 ]
This reverts commit 54fc3c681ded9437e4548e2501dc1136b23cfa9a
which does not allow 1:1 mapping even for the system RAM which
is usually possible.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211108040320.3857636-2-aik@ozlabs.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/iommu.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index e4198700ed1a3..245f1f8df6563 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1034,15 +1034,6 @@ static phys_addr_t ddw_memory_hotplug_max(void)
phys_addr_t max_addr = memory_hotplug_max();
struct device_node *memory;
- /*
- * The "ibm,pmemory" can appear anywhere in the address space.
- * Assuming it is still backed by page structs, set the upper limit
- * for the huge DMA window as MAX_PHYSMEM_BITS.
- */
- if (of_find_node_by_type(NULL, "ibm,pmemory"))
- return (sizeof(phys_addr_t) * 8 <= MAX_PHYSMEM_BITS) ?
- (phys_addr_t) -1 : (1ULL << MAX_PHYSMEM_BITS);
-
for_each_node_by_type(memory, "memory") {
unsigned long start, size;
int n_mem_addr_cells, n_mem_size_cells, len;
--
2.33.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 04/39] powerpc/pseries/ddw: Do not try direct mapping with persistent memory and one window
From: Sasha Levin @ 2021-11-26 2:31 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, leobras.c, Alexey Kardashevskiy, fbarrat,
linuxppc-dev
In-Reply-To: <20211126023156.441292-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit ad3976025b311cdeb822ad3e7a7554018cb0f83f ]
There is a possibility of having just one DMA window available with
a limited capacity which the existing code does not handle that well.
If the window is big enough for the system RAM but less than
MAX_PHYSMEM_BITS (which we want when persistent memory is present),
we create 1:1 window and leave persistent memory without DMA.
This disables 1:1 mapping entirely if there is persistent memory and
either:
- the huge DMA window does not cover the entire address space;
- the default DMA window is removed.
This relies on reverted 54fc3c681ded
("powerpc/pseries/ddw: Extend upper limit for huge DMA window for persistent memory")
to return the actual amount RAM in ddw_memory_hotplug_max() (posted
separately).
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211108040320.3857636-4-aik@ozlabs.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/iommu.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index ad96d6e13d1f6..8322ca86d5acf 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1356,8 +1356,10 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn)
len = order_base_2(query.largest_available_block << page_shift);
win_name = DMA64_PROPNAME;
} else {
- direct_mapping = true;
- win_name = DIRECT64_PROPNAME;
+ direct_mapping = !default_win_removed ||
+ (len == MAX_PHYSMEM_BITS) ||
+ (!pmem_present && (len == max_ram_len));
+ win_name = direct_mapping ? DIRECT64_PROPNAME : DMA64_PROPNAME;
}
ret = create_ddw(dev, ddw_avail, &create, page_shift, len);
--
2.33.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 03/39] powerpc/pseries/ddw: Revert "Extend upper limit for huge DMA window for persistent memory"
From: Sasha Levin @ 2021-11-26 2:31 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, leobras.c, Alexey Kardashevskiy, fbarrat,
linuxppc-dev
In-Reply-To: <20211126023156.441292-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit 2d33f5504490a9d90924476dbccd4a5349ee1ad0 ]
This reverts commit 54fc3c681ded9437e4548e2501dc1136b23cfa9a
which does not allow 1:1 mapping even for the system RAM which
is usually possible.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211108040320.3857636-2-aik@ozlabs.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/iommu.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index a52af8fbf5711..ad96d6e13d1f6 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -1092,15 +1092,6 @@ static phys_addr_t ddw_memory_hotplug_max(void)
phys_addr_t max_addr = memory_hotplug_max();
struct device_node *memory;
- /*
- * The "ibm,pmemory" can appear anywhere in the address space.
- * Assuming it is still backed by page structs, set the upper limit
- * for the huge DMA window as MAX_PHYSMEM_BITS.
- */
- if (of_find_node_by_type(NULL, "ibm,pmemory"))
- return (sizeof(phys_addr_t) * 8 <= MAX_PHYSMEM_BITS) ?
- (phys_addr_t) -1 : (1ULL << MAX_PHYSMEM_BITS);
-
for_each_node_by_type(memory, "memory") {
unsigned long start, size;
int n_mem_addr_cells, n_mem_size_cells, len;
--
2.33.0
^ permalink raw reply related
* [PATCH] powerpc/64s/radix: Fix unmapping huge vmaps when CONFIG_HUGETLB_PAGE=n
From: Nicholas Piggin @ 2021-11-26 2:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
pmd_huge is defined out to false when HUGETLB_PAGE is not configured,
but the vmap code still installs huge PMDs. This leads to errors
encountering bad PMDs when vunmapping because it is not seen as a
huge PTE, and the bad PMD check catches it. The end result may not
be much more serious than some bad pmd warning messages, because the
pmd_none_or_clear_bad() does what we wanted and clears the huge PTE
anyway.
Fix this by checking pmd_is_leaf(), which checks for a PTE regardless
of config options. The whole huge/large/leaf stuff is a tangled mess
but that's kernel-wide and not something we can improve much in
arch/powerpc code.
Fixes: d909f9109c30 ("powerpc/64s/radix: Enable HAVE_ARCH_HUGE_VMAP")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 99dbee114539..7559638068ef 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1089,7 +1089,7 @@ int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
int pud_clear_huge(pud_t *pud)
{
- if (pud_huge(*pud)) {
+ if (pud_is_leaf(*pud)) {
pud_clear(pud);
return 1;
}
@@ -1136,7 +1136,7 @@ int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
int pmd_clear_huge(pmd_t *pmd)
{
- if (pmd_huge(*pmd)) {
+ if (pmd_is_leaf(*pmd)) {
pmd_clear(pmd);
return 1;
}
--
2.23.0
^ permalink raw reply related
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-26 1:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #292347|0 |1
is obsolete| |
--- Comment #36 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299715
--> https://bugzilla.kernel.org/attachment.cgi?id=299715&action=edit
kernel .config (5.15.5, PowerMac G4 DP)
--
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 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-26 1:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #35 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299713
--> https://bugzilla.kernel.org/attachment.cgi?id=299713&action=edit
dmesg (5.15.5, INLINE KASAN, PowerMac G4 DP)
--
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 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-11-26 1:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #34 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 299711
--> https://bugzilla.kernel.org/attachment.cgi?id=299711&action=edit
dmesg (5.15.5, OUTLINE KASAN, PowerMac G4 DP)
Finally my G4 DP got its' fixed & overhauled PSU so I am able to continue here.
Tested kernel 5.15.5 and the original KASAN hit at raid6_pq did not show up.
Instead I am getting this now:
[...]
Running code patching self-tests ...
vmap allocation for size 33562624 failed: use vmalloc=<size> to increase size
swapper/0: vmalloc error: size 33558528, vm_struct allocation failed,
mode:0xcc0(GFP_KERNEL), nodemask=(null)
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
5.15.5-gentoo-PowerMacG4 #5
Call Trace:
[f1033bb0] [c0d933c0] dump_stack_lvl+0x80/0xb0 (unreliable)
[f1033bd0] [c0516128] warn_alloc+0x11c/0x2b4
[f1033cb0] [c0508c40] __vmalloc_node_range+0xd8/0x64c
[f1033d70] [c0508a58] __vmalloc_node+0xec/0xf4
[f1033db0] [c1c0ecb0] test_code_patching+0x72c/0xd50
[f1033df0] [c0008908] do_one_initcall+0x284/0x574
[f1033ec0] [c1c03f78] kernel_init_freeable+0x510/0x51c
[f1033f10] [c000934c] kernel_init+0x24/0x140
[f1033f30] [c0033148] ret_from_kernel_thread+0x14/0x1c
Mem-Info:
active_anon:0 inactive_anon:0 isolated_anon:0
active_file:0 inactive_file:0 isolated_file:0
unevictable:0 dirty:0 writeback:0
slab_reclaimable:1306 slab_unreclaimable:4214
mapped:0 shmem:0 pagetables:0 bounce:0
kernel_misc_reclaimable:0
free:474459 free_pcp:592 free_cma:0
Node 0 active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB
writeback:0kB shmem:0kB writeback_tmp:0kB kernel_stack:840kB pagetables:0kB
all_unreclaimable? no
DMA free:588612kB min:3144kB low:3928kB high:4712kB reserved_highatomic:0KB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:786432kB managed:618264kB mlocked:0kB
bounce:0kB free_pcp:1964kB local_pcp:1568kB free_cma:0kB
lowmem_reserve[]: 0 0 1280 1280
HighMem free:1309224kB min:512kB low:2176kB high:3840kB reserved_highatomic:0KB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:1310720kB managed:1310720kB
mlocked:0kB bounce:0kB free_pcp:404kB local_pcp:116kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0
DMA: 5*4kB (ME) 2*8kB (UM) 4*16kB (M) 5*32kB (ME) 1*64kB (M) 4*128kB (UME)
4*256kB (ME) 4*512kB (UM) 3*1024kB (M) 4*2048kB (ME) 140*4096kB (M) = 588612kB
HighMem: 0*4kB 1*8kB (U) 0*16kB 1*32kB (U) 0*64kB 2*128kB (U) 1*256kB (U)
0*512kB 0*1024kB 1*2048kB (U) 319*4096kB (M) = 1309224kB
0 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
524288 pages RAM
327680 pages HighMem/MovableOnly
42042 pages reserved
code-patching: test failed at line 598
[...]
This makes me wonder whether KASAN is working correctly when not enough vmap
size is available. I did set it to vmalloc=64M via Kernel command line but this
does not seem to be reckognized. Same situation with INLINE KASAN. In both
cases with VMAP_STACK and CONFIG_THREAD_SHIFT=14.
--
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
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