* Re: [PATCH v4 6/6] sched/fair: Consider SMT in ASYM_PACKING load balance
From: Vincent Guittot @ 2021-08-28 13:25 UTC (permalink / raw)
To: Ricardo Neri
Cc: Juri Lelli, Aubrey Li, Srikar Dronamraju, Ravi V. Shankar,
Peter Zijlstra (Intel), Ricardo Neri, Ben Segall,
Srinivas Pandruvada, Joel Fernandes (Google), Ingo Molnar,
Rafael J. Wysocki, Steven Rostedt, Mel Gorman, Len Brown,
Nicholas Piggin, Aubrey Li, Dietmar Eggemann, Tim Chen,
Quentin Perret, Daniel Bristot de Oliveira, linux-kernel,
linuxppc-dev
In-Reply-To: <20210827194503.GB14720@ranerica-svr.sc.intel.com>
On Fri, 27 Aug 2021 at 21:45, Ricardo Neri
<ricardo.neri-calderon@linux.intel.com> wrote:
>
> On Fri, Aug 27, 2021 at 12:13:42PM +0200, Vincent Guittot wrote:
> > On Tue, 10 Aug 2021 at 16:41, Ricardo Neri
> > <ricardo.neri-calderon@linux.intel.com> wrote:
> > > @@ -9540,6 +9629,12 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> > > nr_running == 1)
> > > continue;
> > >
> > > + /* Make sure we only pull tasks from a CPU of lower priority */
> > > + if ((env->sd->flags & SD_ASYM_PACKING) &&
> > > + sched_asym_prefer(i, env->dst_cpu) &&
> > > + nr_running == 1)
> > > + continue;
> >
> > This really looks similar to the test above for SD_ASYM_CPUCAPACITY.
> > More generally speaking SD_ASYM_PACKING and SD_ASYM_CPUCAPACITY share
> > a lot of common policy and I wonder if at some point we could not
> > merge their behavior in LB
>
> I would like to confirm with you that you are not expecting this merge
> as part of this series, right?
Merging them will probably need more tests on both x86 and Arm so I
suppose that we could keep them separate for now
Regards,
Vincent
>
> Thanks and BR,
> Ricardo
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.14-7 tag
From: pr-tracker-bot @ 2021-08-28 18:47 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Linus Torvalds, linux-kernel, npiggin,
lukas.bulwahn
In-Reply-To: <874kb9g2k5.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 28 Aug 2021 22:46:02 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.14-7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9f73eacde73b105d722968e79d0f84fd5034a6f4
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Geoff Levand @ 2021-08-29 0:09 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <4f3113d1-b76e-a085-df2d-fd97d4b45faf@infradead.org>
Hi Christophe,
On 8/27/21 6:34 PM, Geoff Levand wrote:
> On 8/27/21 12:56 PM, Christophe JAILLET wrote:
>> It has *not* been compile tested because I don't have the needed
>> configuration or cross-compiler.
>
> The powerpc ppc64_defconfig has CONFIG_SPIDER_NET set. My
> tdd-builder Docker image has the needed gcc-powerpc-linux-gnu
> cross compiler to build ppc64_defconfig:
>
> https://hub.docker.com/r/glevand/tdd-builder
Just to follow up, I applied your patch to v5.14-rc7 and built
ppc64_defconfig. No warnings or errors were seen.
Thanks for your contribution.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Christophe Leroy @ 2021-08-29 8:01 UTC (permalink / raw)
To: Christophe JAILLET, kou.ishizaki, geoff, davem, kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <60abc3d0c8b4ef8368a4d63326a25a5cb3cd218c.1630094078.git.christophe.jaillet@wanadoo.fr>
Le 27/08/2021 à 21:56, Christophe JAILLET a écrit :
> ---
> It has *not* been compile tested because I don't have the needed
> configuration or cross-compiler. However, the modification is completely
> mechanical and done by coccinelle.
All you need is at https://mirrors.edge.kernel.org/pub/tools/crosstool/
Christophe
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: patchwork-bot+netdevbpf @ 2021-08-29 10:00 UTC (permalink / raw)
To: Christophe JAILLET
Cc: geoff, netdev, kernel-janitors, linux-kernel, kuba, linuxppc-dev,
davem
In-Reply-To: <60abc3d0c8b4ef8368a4d63326a25a5cb3cd218c.1630094078.git.christophe.jaillet@wanadoo.fr>
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 27 Aug 2021 21:56:28 +0200 you wrote:
> In [1], Christoph Hellwig has proposed to remove the wrappers in
> include/linux/pci-dma-compat.h.
>
> Some reasons why this API should be removed have been given by Julia
> Lawall in [2].
>
> A coccinelle script has been used to perform the needed transformation
> Only relevant parts are given below.
>
> [...]
Here is the summary with links:
- net: spider_net: switch from 'pci_' to 'dma_' API
https://git.kernel.org/netdev/net-next/c/27d57f85102b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a555f645f92c58683d0a8d3315352a8d0ce8f80e
From: kernel test robot @ 2021-08-29 10:43 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: a555f645f92c58683d0a8d3315352a8d0ce8f80e Automatic merge of 'next' into merge (2021-08-23 23:59)
elapsed time: 6983m
configs tested: 182
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20210827
powerpc randconfig-c003-20210827
arm omap2plus_defconfig
sparc64 alldefconfig
sparc sparc32_defconfig
mips lemote2f_defconfig
powerpc amigaone_defconfig
mips mtx1_defconfig
csky alldefconfig
powerpc mpc512x_defconfig
sh rts7751r2dplus_defconfig
sh sh7770_generic_defconfig
arm multi_v4t_defconfig
sh migor_defconfig
arm pxa168_defconfig
arm axm55xx_defconfig
powerpc pcm030_defconfig
mips rs90_defconfig
powerpc ppc40x_defconfig
arm ixp4xx_defconfig
arm spear13xx_defconfig
arc vdk_hs38_defconfig
arm spitz_defconfig
mips nlm_xlr_defconfig
arm integrator_defconfig
arm clps711x_defconfig
sh rsk7264_defconfig
mips tb0226_defconfig
powerpc pmac32_defconfig
mips ath79_defconfig
mips allmodconfig
alpha alldefconfig
powerpc ebony_defconfig
arm netwinder_defconfig
arm assabet_defconfig
arm imote2_defconfig
arm shannon_defconfig
arm pxa_defconfig
powerpc lite5200b_defconfig
mips vocore2_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a005-20210824
x86_64 randconfig-a006-20210824
x86_64 randconfig-a001-20210824
x86_64 randconfig-a003-20210824
x86_64 randconfig-a004-20210824
x86_64 randconfig-a002-20210824
i386 randconfig-a006-20210824
i386 randconfig-a001-20210824
i386 randconfig-a002-20210824
i386 randconfig-a005-20210824
i386 randconfig-a003-20210824
i386 randconfig-a004-20210824
x86_64 randconfig-a014-20210827
x86_64 randconfig-a015-20210827
x86_64 randconfig-a016-20210827
x86_64 randconfig-a013-20210827
x86_64 randconfig-a012-20210827
x86_64 randconfig-a011-20210827
x86_64 randconfig-a014-20210825
x86_64 randconfig-a015-20210825
x86_64 randconfig-a016-20210825
x86_64 randconfig-a013-20210825
x86_64 randconfig-a012-20210825
x86_64 randconfig-a011-20210825
i386 randconfig-a011-20210827
i386 randconfig-a016-20210827
i386 randconfig-a012-20210827
i386 randconfig-a014-20210827
i386 randconfig-a013-20210827
i386 randconfig-a015-20210827
i386 randconfig-a011-20210825
i386 randconfig-a016-20210825
i386 randconfig-a012-20210825
i386 randconfig-a014-20210825
i386 randconfig-a013-20210825
i386 randconfig-a015-20210825
arc randconfig-r043-20210825
riscv randconfig-r042-20210825
s390 randconfig-r044-20210825
arc randconfig-r043-20210824
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
s390 randconfig-c005-20210825
i386 randconfig-c001-20210825
arm randconfig-c002-20210825
riscv randconfig-c006-20210825
powerpc randconfig-c003-20210825
x86_64 randconfig-c007-20210825
mips randconfig-c004-20210825
i386 randconfig-c001-20210826
s390 randconfig-c005-20210826
arm randconfig-c002-20210826
riscv randconfig-c006-20210826
powerpc randconfig-c003-20210826
x86_64 randconfig-c007-20210826
mips randconfig-c004-20210826
i386 randconfig-a006-20210825
i386 randconfig-a001-20210825
i386 randconfig-a002-20210825
i386 randconfig-a005-20210825
i386 randconfig-a004-20210825
i386 randconfig-a003-20210825
i386 randconfig-a001-20210829
i386 randconfig-a006-20210829
i386 randconfig-a005-20210829
i386 randconfig-a004-20210829
i386 randconfig-a003-20210829
x86_64 randconfig-a014-20210824
x86_64 randconfig-a015-20210824
x86_64 randconfig-a016-20210824
x86_64 randconfig-a013-20210824
x86_64 randconfig-a012-20210824
x86_64 randconfig-a011-20210824
x86_64 randconfig-a005-20210827
x86_64 randconfig-a001-20210827
x86_64 randconfig-a006-20210827
x86_64 randconfig-a003-20210827
x86_64 randconfig-a004-20210827
x86_64 randconfig-a002-20210827
i386 randconfig-a011-20210824
i386 randconfig-a016-20210824
i386 randconfig-a012-20210824
i386 randconfig-a014-20210824
i386 randconfig-a013-20210824
i386 randconfig-a015-20210824
hexagon randconfig-r041-20210826
hexagon randconfig-r045-20210826
riscv randconfig-r042-20210826
s390 randconfig-r044-20210826
hexagon randconfig-r041-20210824
hexagon randconfig-r045-20210824
riscv randconfig-r042-20210824
s390 randconfig-r044-20210824
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] net: spider_net: switch from 'pci_' to 'dma_' API
From: Michael Ellerman @ 2021-08-29 12:25 UTC (permalink / raw)
To: Christophe Leroy, Christophe JAILLET, kou.ishizaki, geoff, davem,
kuba
Cc: netdev, kernel-janitors, linuxppc-dev, linux-kernel
In-Reply-To: <90220a35-bd0a-ccf3-91b1-c2a459c447e7@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 27/08/2021 à 21:56, Christophe JAILLET a écrit :
>> ---
>> It has *not* been compile tested because I don't have the needed
>> configuration or cross-compiler. However, the modification is completely
>> mechanical and done by coccinelle.
>
> All you need is at https://mirrors.edge.kernel.org/pub/tools/crosstool/
There's also some instructions here for using distro toolchains:
https://github.com/linuxppc/wiki/wiki/Building-powerpc-kernels
cheers
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Nathan Chancellor @ 2021-08-29 18:55 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <03166d569526be70214fe9370a7bad219d2f41c8.1625762907.git.christophe.leroy@csgroup.eu>
Hi Christophe,
On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
> This patch converts powerpc to the generic PTDUMP implementation.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
config [1] when booting up in QEMU with [2]:
[ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
[ 1.623058] Faulting instruction address: 0xc00000000045e5fc
[ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[ 1.625015] Modules linked in:
[ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
[ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
[ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
[ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
[ 1.628449] CFAR: c000000000518300 IRQMASK: 0
[ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
[ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
[ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
[ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
[ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
[ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
[ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
[ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
[ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
[ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
[ 1.635755] Call Trace:
[ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
[ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
[ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
[ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
[ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
[ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
[ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
[ 1.640597] Instruction dump:
[ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
[ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
[ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
[ 1.643220]
[ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
This is not compiler specific, I can reproduce it with GCC 11.2.0 and
binutils 2.37. If there is any additional information I can provide,
please let me know.
[1]: https://src.fedoraproject.org/rpms/kernel/raw/rawhide/f/kernel-ppc64le-fedora.config
[2]: https://github.com/ClangBuiltLinux/boot-utils
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Christophe Leroy @ 2021-08-29 19:11 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <YSvYFTSwP5EkXQZ0@Ryzen-9-3900X.localdomain>
Hi Nathan,
Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
> Hi Christophe,
>
> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>> This patch converts powerpc to the generic PTDUMP implementation.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>
> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
> config [1] when booting up in QEMU with [2]:
>
> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> [ 1.625015] Modules linked in:
> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
> [ 1.635755] Call Trace:
> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
> [ 1.640597] Instruction dump:
> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
> [ 1.643220]
> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>
> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
> binutils 2.37. If there is any additional information I can provide,
> please let me know.
Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
Thanks
Christophe
>
> [1]: https://src.fedoraproject.org/rpms/kernel/raw/rawhide/f/kernel-ppc64le-fedora.config
> [2]: https://github.com/ClangBuiltLinux/boot-utils
>
> Cheers,
> Nathan
>
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Nathan Chancellor @ 2021-08-29 21:39 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <5c479866-f31a-3579-9d71-357c85b777d0@csgroup.eu>
On Sun, Aug 29, 2021 at 09:11:47PM +0200, Christophe Leroy wrote:
> Hi Nathan,
>
> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
> > Hi Christophe,
> >
> > On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
> > > This patch converts powerpc to the generic PTDUMP implementation.
> > >
> > > Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >
> > This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
> > GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
> > config [1] when booting up in QEMU with [2]:
> >
> > [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
> > [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
> > [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
> > [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> > [ 1.625015] Modules linked in:
> > [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
> > [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
> > [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
> > [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
> > [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
> > [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
> > [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
> > [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
> > [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
> > [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
> > [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
> > [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
> > [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
> > [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
> > [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
> > [ 1.635755] Call Trace:
> > [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
> > [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
> > [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
> > [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
> > [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
> > [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
> > [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
> > [ 1.640597] Instruction dump:
> > [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
> > [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
> > [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
> > [ 1.643220]
> > [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> > [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
> >
> > This is not compiler specific, I can reproduce it with GCC 11.2.0 and
> > binutils 2.37. If there is any additional information I can provide,
> > please let me know.
>
> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
Sure thing!
Disassembly of mm/pagewalk.o: https://gist.github.com/2cc2cadc598fe55b0f5cea0d75e89186
vmlinux binary (zstd compressed, 123MB): https://1drv.ms/u/s!AsQNYeB-IEbqjjai5EiHUBiPYzI3?e=kqUwpN
Cheers,
Nathan
^ permalink raw reply
* Re: [RFC PATCH 6/6] powerpc/microwatt: Stop building the hash MMU code
From: Michael Ellerman @ 2021-08-30 3:24 UTC (permalink / raw)
To: Christophe Leroy, Nicholas Piggin, linuxppc-dev
In-Reply-To: <1d1484fe-70db-bafc-016f-29671e941bc8@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Microwatt is radix-only, so stop selecting the hash MMU code.
>>
>> This saves 20kB compressed dtbImage and 56kB vmlinux size.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/configs/microwatt_defconfig | 1 -
>> arch/powerpc/platforms/Kconfig.cputype | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 1 -
>> 3 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>> index bf5f2e5905eb..6fbad42f9e3d 100644
>> --- a/arch/powerpc/configs/microwatt_defconfig
>> +++ b/arch/powerpc/configs/microwatt_defconfig
>> @@ -26,7 +26,6 @@ CONFIG_PPC_MICROWATT=y
>> # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
>> CONFIG_CPU_FREQ=y
>> CONFIG_HZ_100=y
>> -# CONFIG_PPC_MEM_KEYS is not set
>> # CONFIG_SECCOMP is not set
>> # CONFIG_MQ_IOSCHED_KYBER is not set
>> # CONFIG_COREDUMP is not set
>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>> index 9b90fc501ed4..b9acd6c68c81 100644
>> --- a/arch/powerpc/platforms/Kconfig.cputype
>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>> @@ -371,6 +371,7 @@ config SPE
>> config PPC_64S_HASH_MMU
>> bool "Hash MMU Support"
>> depends on PPC_BOOK3S_64
>> + depends on !PPC_MICROWATT
>
> Do we really want to start nit picking which platforms can select such or such option ?
> Isn't it enough to get it off through the defconfig ?
>
> Is PPC_MICROWATT mutually exclusive with other book3s64 configs ? Don't we build multiplatform kernels ?
Yeah that belongs in the microwatt defconfig, not as a forced exclusion
in Kconfig.
cheers
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-08-30 6:51 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <3b419b53-02b8-1a52-2f22-7b8ca49c4460@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:34 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
>> MMU code to be compiled out if radix is selected and the minimum
>> supported CPU type is POWER9 or higher, and KVM is not selected.
>>
>> This saves 128kB kernel image size (90kB text) on powernv_defconfig
>> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>
> ...
>
>> @@ -324,6 +330,7 @@ static inline void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
>> }
>> #endif /* !CONFIG_DEBUG_VM */
>>
>> +#if defined(CONFIG_PPC_RADIX_MMU) && defined(CONFIG_PPC_64S_HASH_MMU)
>> static inline bool radix_enabled(void)
>> {
>> return mmu_has_feature(MMU_FTR_TYPE_RADIX);
>> @@ -333,6 +340,27 @@ static inline bool early_radix_enabled(void)
>> {
>> return early_mmu_has_feature(MMU_FTR_TYPE_RADIX);
>> }
>> +#elif defined(CONFIG_PPC_64S_HASH_MMU)
>> +static inline bool radix_enabled(void)
>> +{
>> + return false;
>> +}
>> +
>> +static inline bool early_radix_enabled(void)
>> +{
>> + return false;
>> +}
>> +#else
>> +static inline bool radix_enabled(void)
>> +{
>> + return true;
>> +}
>> +
>> +static inline bool early_radix_enabled(void)
>> +{
>> + return true;
>> +}
>> +#endif
>
> You don't need something that complex. You don't need to change that at all indeed, just have to
> ensure that when CONFIG_PPC_64S_HASH_MMU is not selected you have MMU_FTR_TYPE_RADIX included in
> MMU_FTRS_ALWAYS and voila.
Yeah I had that as a later patch that fixes up the MMU ftrs for 64s
which does that, I think was required before some of your patches were
upstreamed.
But looks like it is now trivial so I should just pull that in here.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Nicholas Piggin @ 2021-08-30 6:55 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <da2863dc-f8d9-f58b-0d52-7e1bd668718c@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:59 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
>> MMU code to be compiled out if radix is selected and the minimum
>> supported CPU type is POWER9 or higher, and KVM is not selected.
>>
>> This saves 128kB kernel image size (90kB text) on powernv_defconfig
>> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/book3s/64/mmu.h | 22 +++++-
>> .../include/asm/book3s/64/tlbflush-hash.h | 7 ++
>> arch/powerpc/include/asm/book3s/pgtable.h | 4 ++
>> arch/powerpc/include/asm/mmu.h | 38 +++++++++--
>> arch/powerpc/include/asm/mmu_context.h | 2 +
>> arch/powerpc/include/asm/paca.h | 8 +++
>> arch/powerpc/kernel/asm-offsets.c | 2 +
>> arch/powerpc/kernel/dt_cpu_ftrs.c | 10 ++-
>> arch/powerpc/kernel/entry_64.S | 4 +-
>> arch/powerpc/kernel/exceptions-64s.S | 16 +++++
>> arch/powerpc/kernel/mce.c | 2 +-
>> arch/powerpc/kernel/mce_power.c | 10 ++-
>> arch/powerpc/kernel/paca.c | 18 ++---
>> arch/powerpc/kernel/process.c | 13 ++--
>> arch/powerpc/kernel/prom.c | 2 +
>> arch/powerpc/kernel/setup_64.c | 4 ++
>> arch/powerpc/kexec/core_64.c | 4 +-
>> arch/powerpc/kexec/ranges.c | 4 ++
>> arch/powerpc/kvm/Kconfig | 1 +
>> arch/powerpc/mm/book3s64/Makefile | 17 +++--
>> arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
>> arch/powerpc/mm/book3s64/hash_utils.c | 10 ---
>> .../{hash_hugetlbpage.c => hugetlbpage.c} | 6 ++
>> arch/powerpc/mm/book3s64/mmu_context.c | 16 +++++
>> arch/powerpc/mm/book3s64/pgtable.c | 22 +++++-
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++
>> arch/powerpc/mm/book3s64/slb.c | 16 -----
>> arch/powerpc/mm/copro_fault.c | 2 +
>> arch/powerpc/mm/fault.c | 17 +++++
>> arch/powerpc/mm/pgtable.c | 10 ++-
>> arch/powerpc/platforms/Kconfig.cputype | 20 +++++-
>> arch/powerpc/platforms/cell/Kconfig | 1 +
>> arch/powerpc/platforms/maple/Kconfig | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 2 +-
>> arch/powerpc/platforms/pasemi/Kconfig | 1 +
>> arch/powerpc/platforms/powermac/Kconfig | 1 +
>> arch/powerpc/platforms/powernv/Kconfig | 2 +-
>> arch/powerpc/platforms/powernv/idle.c | 2 +
>> arch/powerpc/platforms/powernv/setup.c | 2 +
>> arch/powerpc/platforms/pseries/lpar.c | 68 ++++++++++---------
>> arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
>> arch/powerpc/platforms/pseries/mobility.c | 6 ++
>> arch/powerpc/platforms/pseries/ras.c | 4 ++
>> arch/powerpc/platforms/pseries/reconfig.c | 2 +
>> arch/powerpc/platforms/pseries/setup.c | 6 +-
>> arch/powerpc/xmon/xmon.c | 8 ++-
>> 47 files changed, 310 insertions(+), 111 deletions(-)
>> rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (95%)
>
> Whaou ! Huge patch.
>
> Several places you should be able to use IS_ENABLED() or simply radix_enabled() instead of #ifdefs
> and rely on GCC to opt out stuff when radix_enabled() folds into 'true'.
A lot of it couldn't be done because of data structures but I'm sure I
missed a lot. I will go over it again.
> I may do more detailed comments later when I have time.
Very much appreciated, but let me send out another version before you
get the fine toothed comb out so I don't waste too much of your time.
If there are no objections to the idea from a high level.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 5/6] powerpc/microwatt: select POWER9_CPU
From: Nicholas Piggin @ 2021-08-30 6:56 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <ee10053e-f007-719a-9ab2-a14388c9af9d@csgroup.eu>
Excerpts from Christophe Leroy's message of August 28, 2021 7:50 pm:
>
>
> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>> Microwatt implements a subset of ISA v3.0 which is equivalent to
>> the POWER9_CPU selection.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/configs/microwatt_defconfig | 1 +
>> arch/powerpc/platforms/microwatt/Kconfig | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>> index a08b739123da..bf5f2e5905eb 100644
>> --- a/arch/powerpc/configs/microwatt_defconfig
>> +++ b/arch/powerpc/configs/microwatt_defconfig
>> @@ -14,6 +14,7 @@ CONFIG_EMBEDDED=y
>> # CONFIG_COMPAT_BRK is not set
>> # CONFIG_SLAB_MERGE_DEFAULT is not set
>> CONFIG_PPC64=y
>> +CONFIG_POWER9_CPU=y
>
> That shouldn't be needed in the defconfig because you select it below. You can use make
> savedefconfig to confirm.
Good point.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 6/6] powerpc/microwatt: Stop building the hash MMU code
From: Nicholas Piggin @ 2021-08-30 6:58 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev, Michael Ellerman
In-Reply-To: <87y28jehrt.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of August 30, 2021 1:24 pm:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>>> Microwatt is radix-only, so stop selecting the hash MMU code.
>>>
>>> This saves 20kB compressed dtbImage and 56kB vmlinux size.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/configs/microwatt_defconfig | 1 -
>>> arch/powerpc/platforms/Kconfig.cputype | 1 +
>>> arch/powerpc/platforms/microwatt/Kconfig | 1 -
>>> 3 files changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/powerpc/configs/microwatt_defconfig b/arch/powerpc/configs/microwatt_defconfig
>>> index bf5f2e5905eb..6fbad42f9e3d 100644
>>> --- a/arch/powerpc/configs/microwatt_defconfig
>>> +++ b/arch/powerpc/configs/microwatt_defconfig
>>> @@ -26,7 +26,6 @@ CONFIG_PPC_MICROWATT=y
>>> # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set
>>> CONFIG_CPU_FREQ=y
>>> CONFIG_HZ_100=y
>>> -# CONFIG_PPC_MEM_KEYS is not set
>>> # CONFIG_SECCOMP is not set
>>> # CONFIG_MQ_IOSCHED_KYBER is not set
>>> # CONFIG_COREDUMP is not set
>>> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
>>> index 9b90fc501ed4..b9acd6c68c81 100644
>>> --- a/arch/powerpc/platforms/Kconfig.cputype
>>> +++ b/arch/powerpc/platforms/Kconfig.cputype
>>> @@ -371,6 +371,7 @@ config SPE
>>> config PPC_64S_HASH_MMU
>>> bool "Hash MMU Support"
>>> depends on PPC_BOOK3S_64
>>> + depends on !PPC_MICROWATT
>>
>> Do we really want to start nit picking which platforms can select such or such option ?
>> Isn't it enough to get it off through the defconfig ?
>>
>> Is PPC_MICROWATT mutually exclusive with other book3s64 configs ? Don't we build multiplatform kernels ?
>
> Yeah that belongs in the microwatt defconfig, not as a forced exclusion
> in Kconfig.
Okay I'll fix that up. In that case the select POWER9 should not be in
Kconfig but just defconfig too. Which is fine, it just means oldconfig
won't change it.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 4/6] powerpc/64s: Make hash MMU code build configurable
From: Christophe Leroy @ 2021-08-30 7:12 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <1630306319.j6p7gkgn6s.astroid@bobo.none>
Le 30/08/2021 à 08:55, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of August 28, 2021 7:59 pm:
>>
>>
>> Le 27/08/2021 à 18:34, Nicholas Piggin a écrit :
>>> Introduce a new option CONFIG_PPC_64S_HASH_MMU which allows the 64s hash
>>> MMU code to be compiled out if radix is selected and the minimum
>>> supported CPU type is POWER9 or higher, and KVM is not selected.
>>>
>>> This saves 128kB kernel image size (90kB text) on powernv_defconfig
>>> minus KVM, 350kB on pseries_defconfig minus KVM, 40kB on a tiny config.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/Kconfig | 1 +
>>> arch/powerpc/include/asm/book3s/64/mmu.h | 22 +++++-
>>> .../include/asm/book3s/64/tlbflush-hash.h | 7 ++
>>> arch/powerpc/include/asm/book3s/pgtable.h | 4 ++
>>> arch/powerpc/include/asm/mmu.h | 38 +++++++++--
>>> arch/powerpc/include/asm/mmu_context.h | 2 +
>>> arch/powerpc/include/asm/paca.h | 8 +++
>>> arch/powerpc/kernel/asm-offsets.c | 2 +
>>> arch/powerpc/kernel/dt_cpu_ftrs.c | 10 ++-
>>> arch/powerpc/kernel/entry_64.S | 4 +-
>>> arch/powerpc/kernel/exceptions-64s.S | 16 +++++
>>> arch/powerpc/kernel/mce.c | 2 +-
>>> arch/powerpc/kernel/mce_power.c | 10 ++-
>>> arch/powerpc/kernel/paca.c | 18 ++---
>>> arch/powerpc/kernel/process.c | 13 ++--
>>> arch/powerpc/kernel/prom.c | 2 +
>>> arch/powerpc/kernel/setup_64.c | 4 ++
>>> arch/powerpc/kexec/core_64.c | 4 +-
>>> arch/powerpc/kexec/ranges.c | 4 ++
>>> arch/powerpc/kvm/Kconfig | 1 +
>>> arch/powerpc/mm/book3s64/Makefile | 17 +++--
>>> arch/powerpc/mm/book3s64/hash_pgtable.c | 1 -
>>> arch/powerpc/mm/book3s64/hash_utils.c | 10 ---
>>> .../{hash_hugetlbpage.c => hugetlbpage.c} | 6 ++
>>> arch/powerpc/mm/book3s64/mmu_context.c | 16 +++++
>>> arch/powerpc/mm/book3s64/pgtable.c | 22 +++++-
>>> arch/powerpc/mm/book3s64/radix_pgtable.c | 4 ++
>>> arch/powerpc/mm/book3s64/slb.c | 16 -----
>>> arch/powerpc/mm/copro_fault.c | 2 +
>>> arch/powerpc/mm/fault.c | 17 +++++
>>> arch/powerpc/mm/pgtable.c | 10 ++-
>>> arch/powerpc/platforms/Kconfig.cputype | 20 +++++-
>>> arch/powerpc/platforms/cell/Kconfig | 1 +
>>> arch/powerpc/platforms/maple/Kconfig | 1 +
>>> arch/powerpc/platforms/microwatt/Kconfig | 2 +-
>>> arch/powerpc/platforms/pasemi/Kconfig | 1 +
>>> arch/powerpc/platforms/powermac/Kconfig | 1 +
>>> arch/powerpc/platforms/powernv/Kconfig | 2 +-
>>> arch/powerpc/platforms/powernv/idle.c | 2 +
>>> arch/powerpc/platforms/powernv/setup.c | 2 +
>>> arch/powerpc/platforms/pseries/lpar.c | 68 ++++++++++---------
>>> arch/powerpc/platforms/pseries/lparcfg.c | 2 +-
>>> arch/powerpc/platforms/pseries/mobility.c | 6 ++
>>> arch/powerpc/platforms/pseries/ras.c | 4 ++
>>> arch/powerpc/platforms/pseries/reconfig.c | 2 +
>>> arch/powerpc/platforms/pseries/setup.c | 6 +-
>>> arch/powerpc/xmon/xmon.c | 8 ++-
>>> 47 files changed, 310 insertions(+), 111 deletions(-)
>>> rename arch/powerpc/mm/book3s64/{hash_hugetlbpage.c => hugetlbpage.c} (95%)
>>
>> Whaou ! Huge patch.
>>
>> Several places you should be able to use IS_ENABLED() or simply radix_enabled() instead of #ifdefs
>> and rely on GCC to opt out stuff when radix_enabled() folds into 'true'.
>
> A lot of it couldn't be done because of data structures but I'm sure I
> missed a lot. I will go over it again.
>
>> I may do more detailed comments later when I have time.
>
> Very much appreciated, but let me send out another version before you
> get the fine toothed comb out so I don't waste too much of your time.
One thing that would probably help reduce the size of the patch and help focus on the real changes
would be to put pure code moves in a previous patch I think.
> If there are no objections to the idea from a high level.
I think the idea is good, I always wondered why we kept HASH and RADIX at the same time.
I did similar thing on book3s/32 when I separated 603 and 604+ so that you could build one or the
other or both.
Christophe
^ permalink raw reply
* Re: [linux-next:master 2837/10638] powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/platform/chrome/cros_ec_trace.o' being placed in section `.stubs'
From: Nicholas Piggin @ 2021-08-30 7:19 UTC (permalink / raw)
To: Gwendal Grignou, kernel test robot
Cc: Enric Balletbo i Serra, Linux Memory Management List, kbuild-all,
linuxppc-dev
In-Reply-To: <202108271745.fAmJos3o-lkp@intel.com>
Excerpts from kernel test robot's message of August 27, 2021 7:29 pm:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 88fac11862d38306dd0d2398015744877140390d
> commit: d453ceb6549af8798913de6a20444cb7200fdb69 [2837/10638] platform/chrome: sensorhub: Add trace events for sample
> config: powerpc64-randconfig-r021-20210827 (attached as .config)
> compiler: powerpc64-linux-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d453ceb6549af8798913de6a20444cb7200fdb69
> git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git fetch --no-tags linux-next master
> git checkout d453ceb6549af8798913de6a20444cb7200fdb69
> # save the attached .config to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=powerpc SHELL=/bin/bash
>
> 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 >>):
>
>>> powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/platform/chrome/cros_ec_trace.o' being placed in section `.stubs'
>>> powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/platform/chrome/cros_ec_trace.o' being placed in section `.stubs'
>>> powerpc64-linux-ld: warning: orphan section `.stubs' from `drivers/platform/chrome/cros_ec_trace.o' being placed in section `.stubs'
What creates .stubs? We have something in modules code which does but
not vmlinux code. I can't see anything in modern binutils linker that
creates .stubs. And why is this particular file setting it off? Strange.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/64: handle MSR EE and RI in interrupt entry wrapper
From: Nicholas Piggin @ 2021-08-30 7:32 UTC (permalink / raw)
To: Daniel Axtens, linuxppc-dev
In-Reply-To: <87mtp3e43c.fsf@linkitivity.dja.id.au>
Excerpts from Daniel Axtens's message of August 27, 2021 5:31 pm:
> Hi,
>
>> Similarly to the system call change in the previous patch, the mtmsrd to
>
> I don't actually know what patch this was - I assume it's from a series
> that has since been applied?
Good catch yes that used to be in the same series. Now merged, it's
dd152f, I'll update the changelog.
>> enable RI can be combined with the mtmsrd to enable EE for interrupts
>> which enable the latter, which tends to be the important synchronous
>> interrupts (i.e., page faults).
>>
>> Do this by enabling EE and RI together at the beginning of the entry
>> wrapper if PACA_IRQ_HARD_DIS is clear, and just enabling RI if it is set
>> (which means something wanted EE=0).
>
>
>> diff --git a/arch/powerpc/include/asm/interrupt.h b/arch/powerpc/include/asm/interrupt.h
>> index 6b800d3e2681..e3228a911b35 100644
>> --- a/arch/powerpc/include/asm/interrupt.h
>> +++ b/arch/powerpc/include/asm/interrupt.h
>> @@ -148,9 +148,21 @@ static inline void interrupt_enter_prepare(struct pt_regs *regs, struct interrup
>> #endif
>>
>> #ifdef CONFIG_PPC64
>> - if (irq_soft_mask_set_return(IRQS_ALL_DISABLED) == IRQS_ENABLED)
>> + bool trace_enable = false;
>> +
>> + if (IS_ENABLED(CONFIG_TRACE_IRQFLAGS)) {
>> + if (irq_soft_mask_set_return(IRQS_DISABLED) == IRQS_ENABLED)
>
> In the previous code we had IRQS_ALL_DISABLED, now we just have
> IRQS_DISABLED. Is that intentional?
Hmm, no it should be IRQS_ALL_DISABLED. It doesn't matter much in
practice I think because MSR[EE] is disabled, but obviously shouldn't
be changed by this patch (and shouldn't be changed at all IMO having
ALL_DISABLED).
>
>> + trace_enable = true;
>> + } else {
>> + irq_soft_mask_set(IRQS_DISABLED);
>> + }
>> + /* If the interrupt was taken with HARD_DIS set, don't enable MSR[EE] */
>> + if (local_paca->irq_happened & PACA_IRQ_HARD_DIS)
>> + __hard_RI_enable();
>> + else
>> + __hard_irq_enable();
>> + if (trace_enable)
>> trace_hardirqs_off();
>> - local_paca->irq_happened |= PACA_IRQ_HARD_DIS;
>>
>> if (user_mode(regs)) {
>> CT_WARN_ON(ct_state() != CONTEXT_USER);
>
>
>> @@ -901,11 +892,6 @@ INT_DEFINE_BEGIN(system_reset)
>> IVEC=0x100
>> IAREA=PACA_EXNMI
>> IVIRT=0 /* no virt entry point */
>> - /*
>> - * MSR_RI is not enabled, because PACA_EXNMI and nmi stack is
>> - * being used, so a nested NMI exception would corrupt it.
>> - */
>> - ISET_RI=0
>> ISTACK=0
>> IKVM_REAL=1
>> INT_DEFINE_END(system_reset)
>
>> @@ -986,8 +972,6 @@ EXC_COMMON_BEGIN(system_reset_common)
>
> Right before this change, there's a comment that reads:
>
> /*
> * Increment paca->in_nmi then enable MSR_RI. SLB or MCE will be able
> * to recover, but nested NMI will notice in_nmi and not recover
> ...
>
> You've taken out the bit that enables MSR_RI, which means the comment is
> no longer accurate.
Ah yep, that should be okay because we moved the RI enable to the NMI
entry wrapper. Comment just needs a tweak.
>
> Beyond that, I'm still trying to follow all the various changes in code
> flows. It seems to make at least vague sense: we move the setting of
> MSR_RI from the early asm to interrupt*enter_prepare. I'm just
> struggling to convince myself that when we hit the underlying handler
> that the RI states all line up.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Michael Ellerman @ 2021-08-30 7:52 UTC (permalink / raw)
To: Christophe Leroy, Nathan Chancellor
Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <5c479866-f31a-3579-9d71-357c85b777d0@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Hi Nathan,
>
> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
>> Hi Christophe,
>>
>> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>>> This patch converts powerpc to the generic PTDUMP implementation.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>
>> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
>> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
>> config [1] when booting up in QEMU with [2]:
>>
>> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
>> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
>> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>> [ 1.625015] Modules linked in:
>> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
>> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
>> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
>> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
>> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
>> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
>> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
>> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
>> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
>> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
>> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
>> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
>> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
>> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
>> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
>> [ 1.635755] Call Trace:
>> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
>> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
>> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
>> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
>> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
>> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
>> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
>> [ 1.640597] Instruction dump:
>> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
>> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
>> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
>> [ 1.643220]
>> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>
>> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
>> binutils 2.37. If there is any additional information I can provide,
>> please let me know.
>
> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
It seems to be walking of the end of the pgd.
[ 3.373800] walk_p4d_range: addr c00fff0000000000 end c00fff8000000000
[ 3.373852] walk_p4d_range: addr c00fff8000000000 end c010000000000000 <- end of pgd at PAGE_OFFSET + 4PB
[ 3.373905] walk_p4d_range: addr c010000000000000 end c010008000000000
[ 3.373957] walk_p4d_range: addr c010008000000000 end c010010000000000
[ 3.374009] walk_p4d_range: addr c010010000000000 end c010018000000000
[ 3.374060] walk_p4d_range: addr c010018000000000 end c010020000000000
[ 3.376727] walk_p4d_range: addr c010020000000000 end c010028000000000
[ 3.376780] walk_p4d_range: addr c010028000000000 end c010030000000000
[ 3.376831] walk_p4d_range: addr c010030000000000 end c010038000000000
[ 3.376883] walk_p4d_range: addr c010038000000000 end c010040000000000
[ 3.376935] walk_p4d_range: addr c010040000000000 end c010048000000000
[ 3.376988] walk_p4d_range: addr c010048000000000 end c010050000000000
[ 3.377039] walk_p4d_range: addr c010050000000000 end c010058000000000
[ 3.377091] walk_p4d_range: addr c010058000000000 end c010060000000000
[ 3.377143] walk_p4d_range: addr c010060000000000 end c010068000000000
[ 3.377244] walk_pud_range: addr c010060000000000 end c010068000000000
[ 3.377374] walk_pmd_range: addr c010060100000000 end c010060140000000
[ 3.377817] BUG: Unable to handle kernel data access on read at 0xf906a038d8ba8400
[ 3.378247] Faulting instruction address: 0xc00000000045b4a4
[ 3.378725] Oops: Kernel access of bad area, sig: 11 [#1]
[ 3.378843] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 3.379118] Modules linked in:
[ 3.379422] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc2+ #75
[ 3.379751] NIP: c00000000045b4a4 LR: c00000000045b430 CTR: c000000000b4b580
[ 3.379833] REGS: c0000000085637c0 TRAP: 0300 Not tainted (5.14.0-rc2+)
[ 3.379940] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 8800228f XER: 20040000
[ 3.380284] CFAR: c0000000001f5744 DAR: f906a038d8ba8400 DSISR: 40000000 IRQMASK: 0
[ 3.380284] GPR00: c00000000045b430 c000000008563a60 c0000000028a7d00 000000000000003a
[ 3.380284] GPR04: 00000000ffffe14d c000000008563748 ffffffffffffffff 00000000000001ff
[ 3.380284] GPR08: f906a038d8ba8400 c0100601001fffff c01006013fffffff fffffffffffc51e0
[ 3.380284] GPR12: 0000000000002000 c0000000ffffee80 0000000000000001 c000000008563be0
[ 3.380284] GPR16: c000000001198118 c0000000028daef8 c000000002971a60 c0000000014bc868
[ 3.380284] GPR20: c010060100200000 c000000002971a58 c000000002971a68 c010060100000000
[ 3.380284] GPR24: 0000000000000003 c000000001198118 c000000001198118 c000000001000020
[ 3.380284] GPR28: 0000000000000000 c010060140000000 c010068000000000 f906a038d8ba8400
[ 3.381235] NIP [c00000000045b4a4] __walk_page_range+0x7f4/0xbd0
[ 3.381906] LR [c00000000045b430] __walk_page_range+0x780/0xbd0
[ 3.382120] Call Trace:
[ 3.382240] [c000000008563a60] [c00000000045b430] __walk_page_range+0x780/0xbd0 (unreliable)
[ 3.382445] [c000000008563bc0] [c00000000045ba94] walk_page_range_novma+0x74/0xb0
[ 3.382548] [c000000008563c10] [c000000000514cd8] ptdump_walk_pgd+0x98/0x170
[ 3.382630] [c000000008563c60] [c0000000000aaf70] ptdump_check_wx+0xb0/0x100
[ 3.382774] [c000000008563d40] [c00000000008db18] mark_rodata_ro+0x48/0x80
[ 3.382849] [c000000008563da0] [c000000000012a18] kernel_init+0x78/0x1c0
[ 3.382926] [c000000008563e10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
[ 3.383092] Instruction dump:
[ 3.383341] 78c8f00e 7fe84a14 e9360000 e94100a8 39290010 7dc94836 7e89ba14 7d2900d0
[ 3.383516] 7e944838 3934ffff 7c295040 40800098 <e93f0000> 2c290000 40820094 e9990028
[ 3.384126] ---[ end trace d8e6479034d7a9d1 ]---
cheers
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Christophe Leroy @ 2021-08-30 8:16 UTC (permalink / raw)
To: Michael Ellerman, Nathan Chancellor
Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <87tuj7e5e5.fsf@mpe.ellerman.id.au>
Le 30/08/2021 à 09:52, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Hi Nathan,
>>
>> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
>>> Hi Christophe,
>>>
>>> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>>>> This patch converts powerpc to the generic PTDUMP implementation.
>>>>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>>
>>> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
>>> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
>>> config [1] when booting up in QEMU with [2]:
>>>
>>> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
>>> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
>>> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
>>> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>> [ 1.625015] Modules linked in:
>>> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
>>> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
>>> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
>>> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
>>> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
>>> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
>>> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
>>> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
>>> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
>>> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
>>> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
>>> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
>>> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
>>> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
>>> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
>>> [ 1.635755] Call Trace:
>>> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
>>> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
>>> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
>>> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
>>> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
>>> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
>>> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
>>> [ 1.640597] Instruction dump:
>>> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
>>> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
>>> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
>>> [ 1.643220]
>>> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>>
>>> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
>>> binutils 2.37. If there is any additional information I can provide,
>>> please let me know.
>>
>> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
>
> It seems to be walking of the end of the pgd.
>
> [ 3.373800] walk_p4d_range: addr c00fff0000000000 end c00fff8000000000
> [ 3.373852] walk_p4d_range: addr c00fff8000000000 end c010000000000000 <- end of pgd at PAGE_OFFSET + 4PB
> [ 3.373905] walk_p4d_range: addr c010000000000000 end c010008000000000
Yes, I want it to walk from TASK_SIZE_MAX up to 0xffffffffffffffff :)
static struct ptdump_range ptdump_range[] __ro_after_init = {
{TASK_SIZE_MAX, ~0UL},
{0, 0}
};
Ok, well, ppc32 go up to 0xffffffff
What's the top address to be used for ppc64 ?
^ permalink raw reply
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Michael Ellerman @ 2021-08-30 11:55 UTC (permalink / raw)
To: Christophe Leroy, Nathan Chancellor
Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <2bd9fa19-07b0-c187-c7dd-c6d544e34739@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 30/08/2021 à 09:52, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
>>>> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>>>>> This patch converts powerpc to the generic PTDUMP implementation.
>>>>>
>>>>
>>>> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
>>>> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
>>>> config [1] when booting up in QEMU with [2]:
>>>>
>>>> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
>>>> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
>>>> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
>>>> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>>> [ 1.625015] Modules linked in:
>>>> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
>>>> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
>>>> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
>>>> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
>>>> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
>>>> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
>>>> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
>>>> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
>>>> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
>>>> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
>>>> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
>>>> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
>>>> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
>>>> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
>>>> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
>>>> [ 1.635755] Call Trace:
>>>> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
>>>> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
>>>> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
>>>> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
>>>> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
>>>> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
>>>> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
>>>> [ 1.640597] Instruction dump:
>>>> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
>>>> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
>>>> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
>>>> [ 1.643220]
>>>> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>>> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>>>
>>>> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
>>>> binutils 2.37. If there is any additional information I can provide,
>>>> please let me know.
>>>
>>> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
>>
>> It seems to be walking of the end of the pgd.
>>
>> [ 3.373800] walk_p4d_range: addr c00fff0000000000 end c00fff8000000000
>> [ 3.373852] walk_p4d_range: addr c00fff8000000000 end c010000000000000 <- end of pgd at PAGE_OFFSET + 4PB
>> [ 3.373905] walk_p4d_range: addr c010000000000000 end c010008000000000
>
> Yes, I want it to walk from TASK_SIZE_MAX up to 0xffffffffffffffff :)
But the page table doesn't span that far? 0_o
> static struct ptdump_range ptdump_range[] __ro_after_init = {
> {TASK_SIZE_MAX, ~0UL},
> {0, 0}
> };
>
> Ok, well, ppc32 go up to 0xffffffff
>
> What's the top address to be used for ppc64 ?
It's different for (hash | radix) x page size.
The below works, and matches what we used to do.
Possibly we can come up with something cleaner, not sure.
cheers
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index 2d80d775d15e..3d3778a74969 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -359,6 +359,8 @@ static int __init ptdump_init(void)
ptdump_range[0].start = KERN_VIRT_START;
else
ptdump_range[0].start = PAGE_OFFSET;
+
+ ptdump_range[0].end = ptdump_range[0].start + (PGDIR_SIZE * PTRS_PER_PGD);
#endif
populate_markers();
^ permalink raw reply related
* Re: [PATCH v4 4/4] powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP
From: Christophe Leroy @ 2021-08-30 13:16 UTC (permalink / raw)
To: Michael Ellerman, Nathan Chancellor
Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <87r1ebdu4t.fsf@mpe.ellerman.id.au>
Le 30/08/2021 à 13:55, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> Le 30/08/2021 à 09:52, Michael Ellerman a écrit :
>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>> Le 29/08/2021 à 20:55, Nathan Chancellor a écrit :
>>>>> On Thu, Jul 08, 2021 at 04:49:43PM +0000, Christophe Leroy wrote:
>>>>>> This patch converts powerpc to the generic PTDUMP implementation.
>>>>>>
>>>>>
>>>>> This patch as commit e084728393a5 ("powerpc/ptdump: Convert powerpc to
>>>>> GENERIC_PTDUMP") in powerpc/next causes a panic with Fedora's ppc64le
>>>>> config [1] when booting up in QEMU with [2]:
>>>>>
>>>>> [ 1.621864] BUG: Unable to handle kernel data access on read at 0xc0eeff7f00000000
>>>>> [ 1.623058] Faulting instruction address: 0xc00000000045e5fc
>>>>> [ 1.623832] Oops: Kernel access of bad area, sig: 11 [#1]
>>>>> [ 1.624318] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>>>> [ 1.625015] Modules linked in:
>>>>> [ 1.625463] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc7-next-20210827 #16
>>>>> [ 1.626237] NIP: c00000000045e5fc LR: c00000000045e580 CTR: c000000000518220
>>>>> [ 1.626839] REGS: c00000000752b820 TRAP: 0380 Not tainted (5.14.0-rc7-next-20210827)
>>>>> [ 1.627528] MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 84002482 XER: 20000000
>>>>> [ 1.628449] CFAR: c000000000518300 IRQMASK: 0
>>>>> [ 1.628449] GPR00: c00000000045e580 c00000000752bac0 c0000000028a9300 0000000000000000
>>>>> [ 1.628449] GPR04: c200800000000000 ffffffffffffffff 000000000000000a 0000000000000001
>>>>> [ 1.628449] GPR08: c0eeff7f00000000 0000000000000012 0000000000000000 0000000000000000
>>>>> [ 1.628449] GPR12: 0000000000000000 c000000002b20000 fffffffffffffffe c000000002971a70
>>>>> [ 1.628449] GPR16: c000000002960040 c0000000011a8f98 c00000000752bbf0 ffffffffffffffff
>>>>> [ 1.628449] GPR20: c2008fffffffffff c0eeff7f00000000 c000000002971a68 c00a0003ff000000
>>>>> [ 1.628449] GPR24: c000000002971a78 0000000000000002 0000000000000001 c0000000011a8f98
>>>>> [ 1.628449] GPR28: c0000000011a8f98 c0000000028daef8 c200800000000000 c200900000000000
>>>>> [ 1.634090] NIP [c00000000045e5fc] __walk_page_range+0x2bc/0xce0
>>>>> [ 1.635117] LR [c00000000045e580] __walk_page_range+0x240/0xce0
>>>>> [ 1.635755] Call Trace:
>>>>> [ 1.636018] [c00000000752bac0] [c00000000045e580] __walk_page_range+0x240/0xce0 (unreliable)
>>>>> [ 1.636811] [c00000000752bbd0] [c00000000045f234] walk_page_range_novma+0x74/0xb0
>>>>> [ 1.637459] [c00000000752bc20] [c000000000518448] ptdump_walk_pgd+0x98/0x170
>>>>> [ 1.638138] [c00000000752bc70] [c0000000000aa988] ptdump_check_wx+0x88/0xd0
>>>>> [ 1.638738] [c00000000752bd50] [c00000000008d6d8] mark_rodata_ro+0x48/0x80
>>>>> [ 1.639299] [c00000000752bdb0] [c000000000012a34] kernel_init+0x74/0x1a0
>>>>> [ 1.639842] [c00000000752be10] [c00000000000cfd4] ret_from_kernel_thread+0x5c/0x64
>>>>> [ 1.640597] Instruction dump:
>>>>> [ 1.641021] 38e7ffff 39490010 7ce707b4 7fca5436 79081564 7d4a3838 7908f082 794a1f24
>>>>> [ 1.641740] 78a8f00e 30e6ffff 7ea85214 7ce73110 <7d48502a> 78f90fa4 2c2a0000 39290010
>>>>> [ 1.642771] ---[ end trace 6cf72b085097ad52 ]---
>>>>> [ 1.643220]
>>>>> [ 2.644228] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>>>> [ 2.645523] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
>>>>>
>>>>> This is not compiler specific, I can reproduce it with GCC 11.2.0 and
>>>>> binutils 2.37. If there is any additional information I can provide,
>>>>> please let me know.
>>>>
>>>> Can you provide a dissassembly of __walk_page_range() ? Or provide your vmlinux binary.
>>>
>>> It seems to be walking of the end of the pgd.
>>>
>>> [ 3.373800] walk_p4d_range: addr c00fff0000000000 end c00fff8000000000
>>> [ 3.373852] walk_p4d_range: addr c00fff8000000000 end c010000000000000 <- end of pgd at PAGE_OFFSET + 4PB
>>> [ 3.373905] walk_p4d_range: addr c010000000000000 end c010008000000000
>>
>> Yes, I want it to walk from TASK_SIZE_MAX up to 0xffffffffffffffff :)
>
> But the page table doesn't span that far? 0_o
>
>> static struct ptdump_range ptdump_range[] __ro_after_init = {
>> {TASK_SIZE_MAX, ~0UL},
>> {0, 0}
>> };
>>
>> Ok, well, ppc32 go up to 0xffffffff
>>
>> What's the top address to be used for ppc64 ?
>
> It's different for (hash | radix) x page size.
>
> The below works, and matches what we used to do.
>
> Possibly we can come up with something cleaner, not sure.
>
> cheers
>
>
> diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
> index 2d80d775d15e..3d3778a74969 100644
> --- a/arch/powerpc/mm/ptdump/ptdump.c
> +++ b/arch/powerpc/mm/ptdump/ptdump.c
> @@ -359,6 +359,8 @@ static int __init ptdump_init(void)
> ptdump_range[0].start = KERN_VIRT_START;
> else
> ptdump_range[0].start = PAGE_OFFSET;
> +
> + ptdump_range[0].end = ptdump_range[0].start + (PGDIR_SIZE * PTRS_PER_PGD);
Hum ...
It was:
for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr += PGDIR_SIZE) {
And there is
#define pgd_index(a) (((a) >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1))
Do we have the following ?
pgd_index(KERN_VIRT_START) == 0
Shouldn't it be something like
ptdump_range[0].end = PAGE_OFFSET + (PGDIR_SIZE * PTRS_PER_PGD);
Christophe
^ permalink raw reply
* Re: [PATCH v6 00/11] DDW + Indirect Mapping
From: David Christensen @ 2021-08-30 17:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210817063929.38701-1-leobras.c@gmail.com>
On 8/16/21 11:39 PM, Leonardo Bras wrote:
> So far it's assumed possible to map the guest RAM 1:1 to the bus, which
> works with a small number of devices. SRIOV changes it as the user can
> configure hundreds VFs and since phyp preallocates TCEs and does not
> allow IOMMU pages bigger than 64K, it has to limit the number of TCEs
> per a PE to limit waste of physical pages.
>
> As of today, if the assumed direct mapping is not possible, DDW creation
> is skipped and the default DMA window "ibm,dma-window" is used instead.
>
> Using the DDW instead of the default DMA window may allow to expand the
> amount of memory that can be DMA-mapped, given the number of pages (TCEs)
> may stay the same (or increase) and the default DMA window offers only
> 4k-pages while DDW may offer larger pages (4k, 64k, 16M ...).
So if I'm reading this correctly, VFIO applications requiring hugepage
DMA mappings (e.g. 16M or 2GB) can be supported on an LPAR or DLPAR
after this change, is that correct? Any limitations based on processor
or pHyp revision levels?
Dave
^ permalink raw reply
* Re: [PATCH printk v1 00/10] printk: introduce atomic consoles and sync mode
From: Sergey Senozhatsky @ 2021-08-31 0:33 UTC (permalink / raw)
To: Petr Mladek
Cc: Gautham R. Shenoy, Gustavo A. R. Silva, Srikar Dronamraju,
Jiri Slaby, Peter Zijlstra, Al Cooper, Douglas Anderson,
Paul Cercueil, Matthias Brugger, Paul Mackerras, H. Peter Anvin,
Cengiz Can, Chengyang Fan, Daniel Thompson, Eddie Huang,
Bhaskar Chowdhury, John Ogness, Changbin Du, Masahiro Yamada, x86,
linux-mediatek, Tetsuo Handa, Ingo Molnar, linux-serial,
kgdb-bugreport, linux-mips, Wang Qing, Sergey Senozhatsky,
Paul E. McKenney, Johan Hovold, Steven Rostedt, Borislav Petkov,
Nicholas Piggin, Hsin-Yi Wang, Sedat Dilek, Claire Chang,
Thomas Gleixner, Andy Shevchenko, Andrij Abyzov, linux-arm-kernel,
Sumit Garg, kuldip dwivedi, Andrew Jeffery, Greg Kroah-Hartman,
Zhang Qilong, Nick Desaulniers, linux-kernel, Sergey Senozhatsky,
Guenter Roeck, Jason Wessel, Christophe JAILLET, Andrew Morton,
Maciej W. Rozycki, linuxppc-dev, Vitor Massaru Iha,
Cédric Le Goater
In-Reply-To: <YQwHwT2wYM1dJfVk@alley>
On (21/08/05 17:47), Petr Mladek wrote:
[..]
> 3. After introducing console kthread(s):
>
> int printk(...)
> {
> vprintk_store();
> wake_consoles_via_irqwork();
> }
>
> + in panic:
>
> + with atomic console like after this patchset?
> + without atomic consoles?
>
> + during early boot?
I guess I'd also add netconsole to the list.
^ permalink raw reply
* Re: [PATCH linux-next] power:pkeys: fix bugon.cocci warnings
From: Daniel Axtens @ 2021-08-31 6:01 UTC (permalink / raw)
To: CGEL, Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Sandipan Das, linuxppc-dev, linux-kernel
Cc: Zeal Robot, Jing Yangyang
In-Reply-To: <20210825064228.70487-1-deng.changcheng@zte.com.cn>
Hi Jing,
Thanks for your patch.
The patch looks good, but looking at the output of `make coccicheck
M=arch/powerpc MODE=report`, it looks like there might be a few other
things that we might want to fix. Would it be worth trying to make the
arch/powerpc directory free from coccinelle warnings in one big patch
series, and then we could add coccicheck to our automatic patch testing?
(see
e.g. https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210825064228.70487-1-deng.changcheng@zte.com.cn/ )
For this patch, I think we should try to fix all of arch/powerpc at the
same time. The check points out the following other possible uses of
BUG_ON:
arch/powerpc/include/asm/book3s/64/pgtable-64k.h:68:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON definition in include/asm-generic/bug.h)
arch/powerpc/platforms/cell/spufs/sched.c:908:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON definition in include/asm-generic/bug.h)
arch/powerpc/platforms/powernv/idle.c:968:3-6: WARNING: Use BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON definition in include/asm-generic/bug.h)
arch/powerpc/platforms/powernv/idle.c:456:2-5: WARNING: Use BUG_ON instead of if condition followed by BUG.
Please make sure the condition has no side effects (see conditional BUG_ON definition in include/asm-generic/bug.h)
Kind regards,
Daniel
> Use BUG_ON instead of a if condition followed by BUG.
>
> ./arch/powerpc/include/asm/book3s/64/pkeys.h:21:2-5:WARNING
> Use BUG_ON instead of if condition followed by BUG.
> ./arch/powerpc/include/asm/book3s/64/pkeys.h:14:2-5:WARNING
> Use BUG_ON instead of if condition followed by BUG.
>
> Generated by: scripts/coccinelle/misc/bugon.cocci
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn>
> ---
> arch/powerpc/include/asm/book3s/64/pkeys.h | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/pkeys.h b/arch/powerpc/include/asm/book3s/64/pkeys.h
> index 5b17813..5f74f0c 100644
> --- a/arch/powerpc/include/asm/book3s/64/pkeys.h
> +++ b/arch/powerpc/include/asm/book3s/64/pkeys.h
> @@ -10,15 +10,13 @@ static inline u64 vmflag_to_pte_pkey_bits(u64 vm_flags)
> if (!mmu_has_feature(MMU_FTR_PKEY))
> return 0x0UL;
>
> - if (radix_enabled())
> - BUG();
> + BUG_ON(radix_enabled());
> return hash__vmflag_to_pte_pkey_bits(vm_flags);
> }
>
> static inline u16 pte_to_pkey_bits(u64 pteflags)
> {
> - if (radix_enabled())
> - BUG();
> + BUG_ON(radix_enabled());
> return hash__pte_to_pkey_bits(pteflags);
> }
>
> --
> 1.8.3.1
^ 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