* Re: [RFC 11/20] mm/tlb: remove arch-specific tlb_start/end_vma()
From: Nadav Amit @ 2021-02-02 7:20 UTC (permalink / raw)
To: Nicholas Piggin
Cc: Andrea Arcangeli, linux-s390, X86 ML, Yu Zhao, Peter Zijlstra,
Will Deacon, Dave Hansen, LKML, linux-csky@vger.kernel.org,
Linux-MM, Andy Lutomirski, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <1612247956.0a1r1yjmm3.astroid@bobo.none>
> On Feb 1, 2021, at 10:41 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Peter Zijlstra's message of February 1, 2021 10:09 pm:
>> I also don't think AGRESSIVE_FLUSH_BATCHING quite captures what it does.
>> How about:
>>
>> CONFIG_MMU_GATHER_NO_PER_VMA_FLUSH
>
> Yes please, have to have descriptive names.
Point taken. I will fix it.
>
> I didn't quite see why this was much of an improvement though. Maybe
> follow up patches take advantage of it? I didn't see how they all fit
> together.
They do, but I realized as I said in other emails that I have a serious bug
in the deferred invalidation scheme.
Having said that, I think there is an advantage of having an explicit config
option instead of relying on whether tlb_end_vma is defined. For instance,
Arm does not define tlb_end_vma, and consequently it flushes the TLB after
each VMA. I suspect it is not intentional.
^ permalink raw reply
* Re: [PATCH] powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64 semantics
From: Nicholas Piggin @ 2021-02-02 7:41 UTC (permalink / raw)
To: linuxppc-dev, Raoni Fassina Firmino
In-Reply-To: <20210201200505.iz46ubcizipnkcxe@work-tp>
Excerpts from Raoni Fassina Firmino's message of February 2, 2021 6:05 am:
> Tested on powerpc64 and powerpc64le, with a glibc build and running the
> affected glibc's testcase[2], inspected that glibc's backtrace() now gives
> the correct result and gdb backtrace also keeps working as before.
>
> I believe this should be backported to releases 5.9 and 5.10 as userspace
> is affected in this releases.
>
> ---- 8< ----
Thanks for this, I don't know the glibc code but the kernel change seems
okay to me.
Thanks,
Nick
>
> A Change[1] in __kernel_sigtramp_rt64 VDSO and trampoline code introduced a
> regression in the way glibc's backtrace()[2] detects the signal-handler
> stack frame. Apart from the practical implications, __kernel_sigtram_rt64
> was a VDSO with the semantics that it is a function you can call from
> userspace to end a signal handling. Now this semantics are no longer
> valid.
>
> I believe the aforementioned change affects all releases since 5.9.
>
> This patch tries to fix both the semantics and practical aspect of
> __kernel_sigtramp_rt64 returning it to the previous code, whilst keeping
> the intended behavior from[1] by adding a new symbol to serve as the jump
> target from the kernel to the trampoline. Now the trampoline has two parts,
> an new entry point and the old return point.
>
> [1] commit 0138ba5783ae0dcc799ad401a1e8ac8333790df9 ("powerpc/64/signal:
> Balance return predictor stack in signal trampoline")
> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223194.html
>
> Fixes: 0138ba5783ae ("powerpc/64/signal: Balance return predictor stack in signal trampoline")
> Signed-off-by: Raoni Fassina Firmino <raoni@linux.ibm.com>
> ---
> arch/powerpc/kernel/vdso64/sigtramp.S | 9 ++++++++-
> arch/powerpc/kernel/vdso64/vdso64.lds.S | 2 +-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S b/arch/powerpc/kernel/vdso64/sigtramp.S
> index bbf68cd01088..f0fd8d2a9fc4 100644
> --- a/arch/powerpc/kernel/vdso64/sigtramp.S
> +++ b/arch/powerpc/kernel/vdso64/sigtramp.S
> @@ -15,11 +15,18 @@
>
> .text
>
> +/* __kernel_start_sigtramp_rt64 and __kernel_sigtramp_rt64 together
> + are one function split in two parts. The kernel jumps to the former
> + and the signal handler indirectly (by blr) returns to the latter.
> + __kernel_sigtramp_rt64 needs to point to the return address so
> + glibc can correctly identify the trampoline stack frame. */
Are you planning to update glibc to cope with this as well? Any idea
about musl? If so, including version numbers would be good (not that
it's really a problem to carry this patch around).
I was just about to ask to turn the comment into kernel style, but the
whole file has this style so nevermind about that! :)
Thanks,
Nick
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a2311d1e2b5ea0e77dcdd35fffb58b035da202b6
From: kernel test robot @ 2021-02-02 7:57 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: a2311d1e2b5ea0e77dcdd35fffb58b035da202b6 Automatic merge of 'fixes' into merge (2021-01-31 22:08)
elapsed time: 2645m
configs tested: 136
configs skipped: 2
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
arm vt8500_v6_v7_defconfig
powerpc tqm8xx_defconfig
sh r7785rp_defconfig
arm mvebu_v5_defconfig
sh rts7751r2dplus_defconfig
powerpc redwood_defconfig
arm shmobile_defconfig
arm sama5_defconfig
sparc64 defconfig
mips decstation_r4k_defconfig
mips ar7_defconfig
sh secureedge5410_defconfig
powerpc fsp2_defconfig
mips mpc30x_defconfig
c6x evmc6457_defconfig
sh rsk7203_defconfig
powerpc arches_defconfig
m68k mvme147_defconfig
powerpc tqm8548_defconfig
sh se7780_defconfig
powerpc motionpro_defconfig
arm ep93xx_defconfig
arm multi_v5_defconfig
mips cobalt_defconfig
h8300 defconfig
mips loongson3_defconfig
powerpc mpc8272_ads_defconfig
sh se7751_defconfig
arc hsdk_defconfig
arm mini2440_defconfig
arm assabet_defconfig
mips ip27_defconfig
arm realview_defconfig
m68k sun3x_defconfig
powerpc taishan_defconfig
arm integrator_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210201
x86_64 randconfig-a001-20210201
x86_64 randconfig-a005-20210201
x86_64 randconfig-a002-20210201
x86_64 randconfig-a004-20210201
x86_64 randconfig-a003-20210201
i386 randconfig-a005-20210131
i386 randconfig-a003-20210131
i386 randconfig-a002-20210131
i386 randconfig-a001-20210131
i386 randconfig-a004-20210131
i386 randconfig-a006-20210131
i386 randconfig-a001-20210201
i386 randconfig-a005-20210201
i386 randconfig-a003-20210201
i386 randconfig-a006-20210201
i386 randconfig-a002-20210201
i386 randconfig-a004-20210201
x86_64 randconfig-a015-20210131
x86_64 randconfig-a011-20210131
x86_64 randconfig-a014-20210131
x86_64 randconfig-a016-20210131
x86_64 randconfig-a012-20210131
x86_64 randconfig-a013-20210131
i386 randconfig-a013-20210201
i386 randconfig-a016-20210201
i386 randconfig-a014-20210201
i386 randconfig-a012-20210201
i386 randconfig-a015-20210201
i386 randconfig-a011-20210201
i386 randconfig-a013-20210131
i386 randconfig-a011-20210131
i386 randconfig-a015-20210131
i386 randconfig-a012-20210131
i386 randconfig-a014-20210131
i386 randconfig-a016-20210131
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210131
x86_64 randconfig-a002-20210131
x86_64 randconfig-a001-20210131
x86_64 randconfig-a005-20210131
x86_64 randconfig-a006-20210131
x86_64 randconfig-a003-20210131
x86_64 randconfig-a013-20210201
x86_64 randconfig-a014-20210201
x86_64 randconfig-a015-20210201
x86_64 randconfig-a016-20210201
x86_64 randconfig-a011-20210201
x86_64 randconfig-a012-20210201
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 66f0a9e058fad50e569ad752be72e52701991fd5
From: kernel test robot @ 2021-02-02 7:57 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 66f0a9e058fad50e569ad752be72e52701991fd5 powerpc/vdso64: remove meaningless vgettimeofday.o build rule
elapsed time: 2646m
configs tested: 195
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
powerpc64 defconfig
x86_64 alldefconfig
arm ezx_defconfig
powerpc canyonlands_defconfig
mips maltasmvp_defconfig
arm vt8500_v6_v7_defconfig
powerpc tqm8xx_defconfig
sh r7785rp_defconfig
arm mvebu_v5_defconfig
sh rts7751r2dplus_defconfig
mips workpad_defconfig
powerpc bluestone_defconfig
powerpc walnut_defconfig
sh se7721_defconfig
powerpc tqm8541_defconfig
powerpc amigaone_defconfig
powerpc cell_defconfig
sh sh7785lcr_defconfig
mips cavium_octeon_defconfig
mips db1xxx_defconfig
arm assabet_defconfig
h8300 h8300h-sim_defconfig
arm footbridge_defconfig
arm h5000_defconfig
arm multi_v4t_defconfig
sh sh2007_defconfig
sh se7619_defconfig
mips ar7_defconfig
sh secureedge5410_defconfig
powerpc fsp2_defconfig
mips mpc30x_defconfig
powerpc adder875_defconfig
powerpc powernv_defconfig
sh j2_defconfig
arm mvebu_v7_defconfig
um kunit_defconfig
c6x evmc6457_defconfig
sh rsk7203_defconfig
powerpc arches_defconfig
m68k mvme147_defconfig
powerpc tqm8548_defconfig
sh se7780_defconfig
sh rts7751r2d1_defconfig
sh r7780mp_defconfig
arm s5pv210_defconfig
powerpc motionpro_defconfig
arm ep93xx_defconfig
arm multi_v5_defconfig
mips cobalt_defconfig
xtensa allyesconfig
powerpc katmai_defconfig
powerpc wii_defconfig
mips ip32_defconfig
mips ath25_defconfig
xtensa cadence_csp_defconfig
powerpc maple_defconfig
arm at91_dt_defconfig
powerpc mpc8313_rdb_defconfig
powerpc ppc64e_defconfig
arm clps711x_defconfig
powerpc tqm8555_defconfig
powerpc skiroot_defconfig
powerpc mpc8272_ads_defconfig
sh se7751_defconfig
arc hsdk_defconfig
arm mini2440_defconfig
s390 zfcpdump_defconfig
arm gemini_defconfig
alpha alldefconfig
mips omega2p_defconfig
mips bmips_stb_defconfig
xtensa audio_kc705_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a001-20210201
x86_64 randconfig-a002-20210201
x86_64 randconfig-a004-20210201
x86_64 randconfig-a003-20210201
i386 randconfig-a001-20210202
i386 randconfig-a005-20210202
i386 randconfig-a003-20210202
i386 randconfig-a006-20210202
i386 randconfig-a002-20210202
i386 randconfig-a004-20210202
i386 randconfig-a005-20210131
i386 randconfig-a003-20210131
i386 randconfig-a002-20210131
i386 randconfig-a001-20210131
i386 randconfig-a004-20210131
i386 randconfig-a006-20210131
i386 randconfig-a001-20210201
i386 randconfig-a005-20210201
i386 randconfig-a003-20210201
i386 randconfig-a002-20210201
i386 randconfig-a004-20210201
i386 randconfig-a006-20210201
x86_64 randconfig-a015-20210131
x86_64 randconfig-a011-20210131
x86_64 randconfig-a014-20210131
x86_64 randconfig-a016-20210131
x86_64 randconfig-a012-20210131
x86_64 randconfig-a013-20210131
x86_64 randconfig-a013-20210202
x86_64 randconfig-a014-20210202
x86_64 randconfig-a015-20210202
x86_64 randconfig-a016-20210202
x86_64 randconfig-a011-20210202
x86_64 randconfig-a012-20210202
i386 randconfig-a013-20210202
i386 randconfig-a016-20210202
i386 randconfig-a014-20210202
i386 randconfig-a012-20210202
i386 randconfig-a015-20210202
i386 randconfig-a011-20210202
i386 randconfig-a013-20210131
i386 randconfig-a011-20210131
i386 randconfig-a015-20210131
i386 randconfig-a012-20210131
i386 randconfig-a014-20210131
i386 randconfig-a016-20210131
i386 randconfig-a013-20210201
i386 randconfig-a014-20210201
i386 randconfig-a012-20210201
i386 randconfig-a011-20210201
i386 randconfig-a016-20210201
i386 randconfig-a015-20210201
x86_64 randconfig-a006-20210201
x86_64 randconfig-a005-20210201
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210202
x86_64 randconfig-a001-20210202
x86_64 randconfig-a005-20210202
x86_64 randconfig-a002-20210202
x86_64 randconfig-a004-20210202
x86_64 randconfig-a003-20210202
x86_64 randconfig-a004-20210131
x86_64 randconfig-a002-20210131
x86_64 randconfig-a001-20210131
x86_64 randconfig-a005-20210131
x86_64 randconfig-a006-20210131
x86_64 randconfig-a003-20210131
x86_64 randconfig-a013-20210201
x86_64 randconfig-a014-20210201
x86_64 randconfig-a015-20210201
x86_64 randconfig-a016-20210201
x86_64 randconfig-a011-20210201
x86_64 randconfig-a012-20210201
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS 6895c5ba7bdcc55eacad03cf309ab23be63b9cac
From: kernel test robot @ 2021-02-02 7:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: 6895c5ba7bdcc55eacad03cf309ab23be63b9cac powerpc/xmon: Select CONSOLE_POLL for the 8xx
elapsed time: 2644m
configs tested: 197
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
arm vt8500_v6_v7_defconfig
powerpc tqm8xx_defconfig
sh r7785rp_defconfig
arm mvebu_v5_defconfig
sh rts7751r2dplus_defconfig
openrisc alldefconfig
powerpc ppc6xx_defconfig
arm vexpress_defconfig
mips bmips_be_defconfig
h8300 h8300h-sim_defconfig
mips vocore2_defconfig
mips cavium_octeon_defconfig
mips db1xxx_defconfig
arm assabet_defconfig
mips ar7_defconfig
sh secureedge5410_defconfig
powerpc fsp2_defconfig
mips mpc30x_defconfig
powerpc tqm8541_defconfig
xtensa virt_defconfig
arm mxs_defconfig
powerpc acadia_defconfig
sh sh2007_defconfig
mips e55_defconfig
c6x evmc6457_defconfig
sh rsk7203_defconfig
powerpc arches_defconfig
m68k mvme147_defconfig
powerpc tqm8548_defconfig
sh se7780_defconfig
sh rts7751r2d1_defconfig
powerpc amigaone_defconfig
sh r7780mp_defconfig
arm s5pv210_defconfig
arm ezx_defconfig
arm cm_x300_defconfig
xtensa xip_kc705_defconfig
m68k m5475evb_defconfig
arm pleb_defconfig
sh migor_defconfig
arm nhk8815_defconfig
powerpc motionpro_defconfig
arm ep93xx_defconfig
arm multi_v5_defconfig
mips cobalt_defconfig
powerpc pasemi_defconfig
mips malta_qemu_32r6_defconfig
powerpc mpc85xx_cds_defconfig
mips sb1250_swarm_defconfig
xtensa allyesconfig
powerpc katmai_defconfig
powerpc wii_defconfig
mips ip32_defconfig
mips ath25_defconfig
xtensa cadence_csp_defconfig
powerpc maple_defconfig
arm at91_dt_defconfig
powerpc walnut_defconfig
powerpc mpc8313_rdb_defconfig
powerpc ppc64e_defconfig
arm clps711x_defconfig
powerpc tqm8555_defconfig
arm multi_v4t_defconfig
powerpc skiroot_defconfig
powerpc mpc8272_ads_defconfig
sh se7751_defconfig
arc hsdk_defconfig
arm mini2440_defconfig
s390 zfcpdump_defconfig
arm gemini_defconfig
alpha alldefconfig
mips omega2p_defconfig
mips bmips_stb_defconfig
xtensa audio_kc705_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a006-20210201
x86_64 randconfig-a001-20210201
x86_64 randconfig-a005-20210201
x86_64 randconfig-a002-20210201
x86_64 randconfig-a004-20210201
x86_64 randconfig-a003-20210201
i386 randconfig-a001-20210202
i386 randconfig-a005-20210202
i386 randconfig-a003-20210202
i386 randconfig-a006-20210202
i386 randconfig-a002-20210202
i386 randconfig-a004-20210202
i386 randconfig-a005-20210131
i386 randconfig-a003-20210131
i386 randconfig-a002-20210131
i386 randconfig-a001-20210131
i386 randconfig-a004-20210131
i386 randconfig-a006-20210131
i386 randconfig-a001-20210201
i386 randconfig-a005-20210201
i386 randconfig-a003-20210201
i386 randconfig-a006-20210201
i386 randconfig-a002-20210201
i386 randconfig-a004-20210201
x86_64 randconfig-a015-20210131
x86_64 randconfig-a011-20210131
x86_64 randconfig-a014-20210131
x86_64 randconfig-a016-20210131
x86_64 randconfig-a012-20210131
x86_64 randconfig-a013-20210131
x86_64 randconfig-a013-20210202
x86_64 randconfig-a014-20210202
x86_64 randconfig-a015-20210202
x86_64 randconfig-a016-20210202
x86_64 randconfig-a011-20210202
x86_64 randconfig-a012-20210202
i386 randconfig-a013-20210202
i386 randconfig-a016-20210202
i386 randconfig-a014-20210202
i386 randconfig-a012-20210202
i386 randconfig-a015-20210202
i386 randconfig-a011-20210202
i386 randconfig-a013-20210131
i386 randconfig-a011-20210131
i386 randconfig-a015-20210131
i386 randconfig-a012-20210131
i386 randconfig-a014-20210131
i386 randconfig-a016-20210131
i386 randconfig-a013-20210201
i386 randconfig-a016-20210201
i386 randconfig-a014-20210201
i386 randconfig-a012-20210201
i386 randconfig-a015-20210201
i386 randconfig-a011-20210201
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20210202
x86_64 randconfig-a001-20210202
x86_64 randconfig-a005-20210202
x86_64 randconfig-a002-20210202
x86_64 randconfig-a004-20210202
x86_64 randconfig-a003-20210202
x86_64 randconfig-a004-20210131
x86_64 randconfig-a002-20210131
x86_64 randconfig-a001-20210131
x86_64 randconfig-a005-20210131
x86_64 randconfig-a006-20210131
x86_64 randconfig-a003-20210131
x86_64 randconfig-a013-20210201
x86_64 randconfig-a014-20210201
x86_64 randconfig-a015-20210201
x86_64 randconfig-a016-20210201
x86_64 randconfig-a011-20210201
x86_64 randconfig-a012-20210201
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS WITH WARNING 30133c32d19c678dbd9da28ace3aac35eb5dd4c9
From: kernel test robot @ 2021-02-02 7:58 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: 30133c32d19c678dbd9da28ace3aac35eb5dd4c9 Fixup powermac PCI
Warning in current branch:
arch/powerpc/kernel/pci-common.c:1704:12: warning: no previous prototype for 'discover_phbs' [-Wmissing-prototypes]
arch/powerpc/kernel/pci-common.c:1704:12: warning: no previous prototype for function 'discover_phbs' [-Wmissing-prototypes]
Warning ids grouped by kconfigs:
gcc_recent_errors
`-- powerpc-allyesconfig
`-- arch-powerpc-kernel-pci-common.c:warning:no-previous-prototype-for-discover_phbs
clang_recent_errors
`-- powerpc-randconfig-r033-20210131
`-- arch-powerpc-kernel-pci-common.c:warning:no-previous-prototype-for-function-discover_phbs
elapsed time: 2644m
configs tested: 151
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm vt8500_v6_v7_defconfig
powerpc tqm8xx_defconfig
sh r7785rp_defconfig
arm mvebu_v5_defconfig
sh rts7751r2dplus_defconfig
mips workpad_defconfig
powerpc bluestone_defconfig
powerpc walnut_defconfig
sh se7721_defconfig
sh sh2007_defconfig
ia64 alldefconfig
c6x evmc6457_defconfig
sh rsk7203_defconfig
powerpc arches_defconfig
m68k mvme147_defconfig
powerpc tqm8548_defconfig
sh se7780_defconfig
powerpc motionpro_defconfig
arm ep93xx_defconfig
arm multi_v5_defconfig
mips cobalt_defconfig
arm pleb_defconfig
arm stm32_defconfig
powerpc tqm8555_defconfig
powerpc taishan_defconfig
arm alldefconfig
powerpc maple_defconfig
arm at91_dt_defconfig
powerpc mpc8313_rdb_defconfig
powerpc ppc64e_defconfig
arc axs103_smp_defconfig
sh sh03_defconfig
mips mtx1_defconfig
mips malta_defconfig
powerpc mpc8272_ads_defconfig
sh se7751_defconfig
arc hsdk_defconfig
arm mini2440_defconfig
arm assabet_defconfig
s390 zfcpdump_defconfig
arm gemini_defconfig
alpha alldefconfig
mips omega2p_defconfig
mips bmips_stb_defconfig
xtensa audio_kc705_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 tinyconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210201
i386 randconfig-a005-20210201
i386 randconfig-a003-20210201
i386 randconfig-a006-20210201
i386 randconfig-a002-20210201
i386 randconfig-a004-20210201
i386 randconfig-a005-20210131
i386 randconfig-a003-20210131
i386 randconfig-a002-20210131
i386 randconfig-a001-20210131
i386 randconfig-a004-20210131
i386 randconfig-a006-20210131
x86_64 randconfig-a015-20210131
x86_64 randconfig-a011-20210131
x86_64 randconfig-a014-20210131
x86_64 randconfig-a016-20210131
x86_64 randconfig-a012-20210131
x86_64 randconfig-a013-20210131
x86_64 randconfig-a013-20210202
x86_64 randconfig-a014-20210202
x86_64 randconfig-a015-20210202
x86_64 randconfig-a016-20210202
x86_64 randconfig-a011-20210202
x86_64 randconfig-a012-20210202
i386 randconfig-a013-20210131
i386 randconfig-a011-20210131
i386 randconfig-a015-20210131
i386 randconfig-a012-20210131
i386 randconfig-a014-20210131
i386 randconfig-a016-20210131
i386 randconfig-a013-20210201
i386 randconfig-a016-20210201
i386 randconfig-a014-20210201
i386 randconfig-a012-20210201
i386 randconfig-a015-20210201
i386 randconfig-a011-20210201
x86_64 randconfig-a006-20210201
x86_64 randconfig-a001-20210201
x86_64 randconfig-a005-20210201
x86_64 randconfig-a002-20210201
x86_64 randconfig-a004-20210201
x86_64 randconfig-a003-20210201
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-a004-20210131
x86_64 randconfig-a002-20210131
x86_64 randconfig-a001-20210131
x86_64 randconfig-a005-20210131
x86_64 randconfig-a006-20210131
x86_64 randconfig-a003-20210131
x86_64 randconfig-a013-20210201
x86_64 randconfig-a014-20210201
x86_64 randconfig-a015-20210201
x86_64 randconfig-a016-20210201
x86_64 randconfig-a011-20210201
x86_64 randconfig-a012-20210201
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [RFC PATCH 3/6] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210202091116.196134-1-aneesh.kumar@linux.ibm.com>
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index f554320281cc..54fd2302b99d 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -27,6 +27,7 @@
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
#include "internal.h"
@@ -258,9 +259,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd_clear(old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
+ pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- /* Set the new pmd */
- set_pmd_at(mm, new_addr, new_pmd, pmd);
flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
@@ -307,8 +307,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
- /* Set the new pud */
- set_pud_at(mm, new_addr, new_pud, pud);
+ pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
--
2.29.2
^ permalink raw reply related
* [RFC PATCH 1/6] selftest/mremap_test: Update the test to handle pagesize other than 4K
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 113 ++++++++++++-----------
1 file changed, 61 insertions(+), 52 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index 9c391d016922..c9a5461eb786 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -45,14 +45,15 @@ enum {
_4MB = 4ULL << 20,
_1GB = 1ULL << 30,
_2GB = 2ULL << 30,
- PTE = _4KB,
PMD = _2MB,
PUD = _1GB,
};
+#define PTE page_size
+
#define MAKE_TEST(source_align, destination_align, size, \
overlaps, should_fail, test_name) \
-{ \
+(struct test){ \
.name = test_name, \
.config = { \
.src_alignment = source_align, \
@@ -252,12 +253,17 @@ static int parse_args(int argc, char **argv, unsigned int *threshold_mb,
return 0;
}
+#define MAX_TEST 13
+#define MAX_PERF_TEST 3
int main(int argc, char **argv)
{
int failures = 0;
int i, run_perf_tests;
unsigned int threshold_mb = VALIDATION_DEFAULT_THRESHOLD;
unsigned int pattern_seed;
+ struct test test_cases[MAX_TEST];
+ struct test perf_test_cases[MAX_PERF_TEST];
+ int page_size;
time_t t;
pattern_seed = (unsigned int) time(&t);
@@ -268,56 +274,59 @@ int main(int argc, char **argv)
ksft_print_msg("Test configs:\n\tthreshold_mb=%u\n\tpattern_seed=%u\n\n",
threshold_mb, pattern_seed);
- struct test test_cases[] = {
- /* Expected mremap failures */
- MAKE_TEST(_4KB, _4KB, _4KB, OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source and Destination Regions Overlapping"),
- MAKE_TEST(_4KB, _1KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Destination Address Misaligned (1KB-aligned)"),
- MAKE_TEST(_1KB, _4KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source Address Misaligned (1KB-aligned)"),
-
- /* Src addr PTE aligned */
- MAKE_TEST(PTE, PTE, _8KB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "8KB mremap - Source PTE-aligned, Destination PTE-aligned"),
-
- /* Src addr 1MB aligned */
- MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination PTE-aligned"),
- MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned"),
-
- /* Src addr PMD aligned */
- MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PMD-aligned"),
-
- /* Src addr PUD aligned */
- MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
-
- struct test perf_test_cases[] = {
- /*
- * mremap 1GB region - Page table level aligned time
- * comparison.
- */
- MAKE_TEST(PTE, PTE, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PTE-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PMD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
+ page_size = sysconf(_SC_PAGESIZE);
+
+ /* Expected mremap failures */
+ test_cases[0] = MAKE_TEST(page_size, page_size, page_size,
+ OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source and Destination Regions Overlapping");
+
+ test_cases[1] = MAKE_TEST(page_size, page_size/4, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Destination Address Misaligned (1KB-aligned)");
+ test_cases[2] = MAKE_TEST(page_size/4, page_size, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source Address Misaligned (1KB-aligned)");
+
+ /* Src addr PTE aligned */
+ test_cases[3] = MAKE_TEST(PTE, PTE, PTE * 2,
+ NON_OVERLAPPING, EXPECT_SUCCESS,
+ "8KB mremap - Source PTE-aligned, Destination PTE-aligned");
+
+ /* Src addr 1MB aligned */
+ test_cases[4] = MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination PTE-aligned");
+ test_cases[5] = MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned");
+
+ /* Src addr PMD aligned */
+ test_cases[6] = MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PTE-aligned");
+ test_cases[7] = MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination 1MB-aligned");
+ test_cases[8] = MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PMD-aligned");
+
+ /* Src addr PUD aligned */
+ test_cases[9] = MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PTE-aligned");
+ test_cases[10] = MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination 1MB-aligned");
+ test_cases[11] = MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PMD-aligned");
+ test_cases[12] = MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PUD-aligned");
+
+ perf_test_cases[0] = MAKE_TEST(page_size, page_size, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PTE-aligned, Destination PTE-aligned");
+ /*
+ * mremap 1GB region - Page table level aligned time
+ * comparison.
+ */
+ perf_test_cases[1] = MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PMD-aligned, Destination PMD-aligned");
+ perf_test_cases[2] = MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PUD-aligned, Destination PUD-aligned");
run_perf_tests = (threshold_mb == VALIDATION_NO_THRESHOLD) ||
(threshold_mb * _1MB >= _1GB);
--
2.29.2
^ permalink raw reply related
* [RFC PATCH 4/6] mm/mremap: Use mmu gather interface instead of flush_tlb_range
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210202091116.196134-1-aneesh.kumar@linux.ibm.com>
Some architectures do have the concept of page walk cache and only mmu gather
interface supports flushing them. A fast mremap that involves moving page
table pages instead of copying pte entries should flush page walk cache since
the old translation cache is no more valid. Hence switch to mm gather to flush
TLB and mark tlb.freed_tables = 1. No page table pages need to be freed here.
With this the tlb flush is done outside page table lock (ptl).
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 54fd2302b99d..14778d215011 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -217,6 +217,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
{
spinlock_t *old_ptl, *new_ptl;
struct mm_struct *mm = vma->vm_mm;
+ struct mmu_gather tlb;
pmd_t pmd;
/*
@@ -245,11 +246,12 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
if (WARN_ON_ONCE(!pmd_none(*new_pmd)))
return false;
+ tlb_gather_mmu(&tlb, mm, old_addr, PMD_SIZE);
/*
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pmd_lock(vma->vm_mm, old_pmd);
+ old_ptl = pmd_lock(mm, old_pmd);
new_ptl = pmd_lockptr(mm, new_pmd);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -258,13 +260,23 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd = *old_pmd;
pmd_clear(old_pmd);
+ /*
+ * Mark the range. We are not freeing page table pages nor
+ * regular pages. Hence we don't need to call tlb_remove_table()
+ * or tlb_remove_page().
+ */
+ tlb_flush_pte_range(&tlb, old_addr, PMD_SIZE);
+ tlb.freed_tables = 1;
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ /*
+ * This will invalidate both the old TLB and page table walk caches.
+ */
+ tlb_finish_mmu(&tlb, old_addr, PMD_SIZE);
return true;
}
@@ -283,6 +295,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
{
spinlock_t *old_ptl, *new_ptl;
struct mm_struct *mm = vma->vm_mm;
+ struct mmu_gather tlb;
pud_t pud;
/*
@@ -292,11 +305,12 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
if (WARN_ON_ONCE(!pud_none(*new_pud)))
return false;
+ tlb_gather_mmu(&tlb, mm, old_addr, PUD_SIZE);
/*
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pud_lock(vma->vm_mm, old_pud);
+ old_ptl = pud_lock(mm, old_pud);
new_ptl = pud_lockptr(mm, new_pud);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -305,14 +319,25 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
pud = *old_pud;
pud_clear(old_pud);
+ /*
+ * Mark the range. We are not freeing page table pages nor
+ * regular pages. Hence we don't need to call tlb_remove_table()
+ * or tlb_remove_page().
+ */
+ tlb_flush_pte_range(&tlb, old_addr, PUD_SIZE);
+ tlb.freed_tables = 1;
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
- flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ /*
+ * This will invalidate both the old TLB and page table walk caches.
+ */
+ tlb_finish_mmu(&tlb, old_addr, PUD_SIZE);
return true;
}
#else
--
2.29.2
^ permalink raw reply related
* [RFC PATCH 2/6] selftest/mremap_test: Avoid crash with static build
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210202091116.196134-1-aneesh.kumar@linux.ibm.com>
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index c9a5461eb786..0624d1bd71b5 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -75,9 +75,10 @@ static void *get_source_mapping(struct config c)
retry:
addr += c.src_alignment;
src_addr = mmap((void *) addr, c.region_size, PROT_READ | PROT_WRITE,
- MAP_FIXED | MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+ MAP_FIXED_NOREPLACE | MAP_ANONYMOUS | MAP_SHARED,
+ -1, 0);
if (src_addr == MAP_FAILED) {
- if (errno == EPERM)
+ if (errno == EPERM || errno == EEXIST)
goto retry;
goto error;
}
--
2.29.2
^ permalink raw reply related
* [RFC PATCH 5/6] mm/mremap: Allow arch runtime override
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210202091116.196134-1-aneesh.kumar@linux.ibm.com>
Architectures like ppc64 can only support faster mremap only with radix
translation. Hence allow a runtime check w.r.t support for fast mremap.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/arm64/include/asm/tlb.h | 6 ++++++
arch/powerpc/include/asm/tlb.h | 6 ++++++
arch/x86/include/asm/tlb.h | 5 +++++
mm/mremap.c | 14 +++++++++++++-
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index 61c97d3b58c7..fe209efc6a10 100644
--- a/arch/arm64/include/asm/tlb.h
+++ b/arch/arm64/include/asm/tlb.h
@@ -94,4 +94,10 @@ static inline void __pud_free_tlb(struct mmu_gather *tlb, pud_t *pudp,
}
#endif
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return true;
+}
+
#endif
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 160422a439aa..058918a7cd3c 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -83,5 +83,11 @@ static inline int mm_is_thread_local(struct mm_struct *mm)
}
#endif
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return radix_enabled();
+}
+
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_TLB_H */
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index 820082bd6880..62827553afd8 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -38,4 +38,9 @@ static inline void __tlb_remove_table(void *table)
free_page_and_swap_cache(table);
}
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return true;
+}
#endif /* _ASM_X86_TLB_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index 14778d215011..dd1244a410bb 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -26,7 +26,7 @@
#include <linux/userfaultfd_k.h>
#include <asm/cacheflush.h>
-#include <asm/tlbflush.h>
+#include <asm/tlb.h>
#include <asm/pgalloc.h>
#include "internal.h"
@@ -211,6 +211,14 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
drop_rmap_locks(vma);
}
+#ifndef arch_supports_page_tables_move
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return false;
+}
+#endif
+
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
@@ -220,6 +228,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
struct mmu_gather tlb;
pmd_t pmd;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pmd shouldn't be established, free_pgtables()
* should have released it.
@@ -298,6 +308,8 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
struct mmu_gather tlb;
pud_t pud;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pud shouldn't be established, free_pgtables()
* should have released it.
--
2.29.2
^ permalink raw reply related
* [RFC PATCH 6/6] powerpc/mm: Enable move pmd/pud
From: Aneesh Kumar K.V @ 2021-02-02 9:11 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210202091116.196134-1-aneesh.kumar@linux.ibm.com>
mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
1GB mremap - Source PTE-aligned, Destination PTE-aligned
mremap time: 1114318ns
1GB mremap - Source PMD-aligned, Destination PMD-aligned
mremap time: 1097715ns
1GB mremap - Source PUD-aligned, Destination PUD-aligned
mremap time: 26851ns
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/platforms/Kconfig.cputype | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 3ce907523b1e..2e666e569fdf 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -97,6 +97,8 @@ config PPC_BOOK3S_64
select PPC_HAVE_PMU_SUPPORT
select SYS_SUPPORTS_HUGETLBFS
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
+ select HAVE_MOVE_PMD
+ select HAVE_MOVE_PUD
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
select ARCH_SUPPORTS_NUMA_BALANCING
select IRQ_WORK
--
2.29.2
^ permalink raw reply related
* [PATCH kernel] powerpc/uaccess: Skip might_fault() when user access is enabled
From: Alexey Kardashevskiy @ 2021-02-02 9:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Nicholas Piggin
The amount of code executed with enabled user space access (unlocked KUAP)
should be minimal. However with CONFIG_PROVE_LOCKING or
CONFIG_DEBUG_ATOMIC_SLEEP enabled, might_fault() may end up replaying
interrupts which in turn may access the user space and forget to restore
the KUAP state.
The problem places are strncpy_from_user (and similar) which unlock KUAP
and call unsafe_get_user -> __get_user_allowed -> __get_user_nocheck()
with do_allow=false to skip KUAP as the caller took care of it.
This changes __get_user_nocheck() to look at @do_allow to decide whether
to skip might_fault(). Since strncpy_from_user/etc call might_fault()
anyway before unlocking KUAP, there should be no visible change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
This an attempt to fix that KUAP restore problem from
"powerpc/kuap: Restore AMR after replaying soft interrupts".
---
arch/powerpc/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 501c9a79038c..cd6c0427a9e2 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -313,7 +313,7 @@ do { \
__typeof__(size) __gu_size = (size); \
\
__chk_user_ptr(__gu_addr); \
- if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ if (!do_allow && !is_kernel_addr((unsigned long)__gu_addr)) \
might_fault(); \
barrier_nospec(); \
if (do_allow) \
--
2.17.1
^ permalink raw reply related
* [PATCH kernel] powerpc/kuap: Restore AMR after replaying soft interrupts
From: Alexey Kardashevskiy @ 2021-02-02 9:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Nicholas Piggin
Since de78a9c "powerpc: Add a framework for Kernel Userspace Access
Protection", user access helpers call user_{read|write}_access_{begin|end}
when user space access is allowed.
890274c "powerpc/64s: Implement KUAP for Radix MMU" made the mentioned
helpers program a AMR special register to allow such access for a short
period of time, most of the time AMR is expected to block user memory
access by the kernel.
Since the code accesses the user space memory, unsafe_get_user()
calls might_fault() which calls arch_local_irq_restore() if either
CONFIG_PROVE_LOCKING or CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
arch_local_irq_restore() then attempts to replay pending soft interrupts
as KUAP regions have hardware interrupts enabled.
If a pending interrupt happens to do user access (performance interrupts
do that), it enables access for a short period of time so after returning
from the replay, the user access state remains blocked and if a user page
fault happens - "Bug: Read fault blocked by AMR!" appears and SIGSEGV is
sent.
This saves/restores AMR when replaying interrupts.
This adds a check if AMR was not blocked when before replaying interrupts.
Found by syzkaller. The call stack for the bug is:
copy_from_user_nofault+0xf8/0x250
perf_callchain_user_64+0x3d8/0x8d0
perf_callchain_user+0x38/0x50
get_perf_callchain+0x28c/0x300
perf_callchain+0xb0/0x130
perf_prepare_sample+0x364/0xbf0
perf_event_output_forward+0xe0/0x280
__perf_event_overflow+0xa4/0x240
perf_swevent_hrtimer+0x1d4/0x1f0
__hrtimer_run_queues+0x328/0x900
hrtimer_interrupt+0x128/0x350
timer_interrupt+0x180/0x600
replay_soft_interrupts+0x21c/0x4f0
arch_local_irq_restore+0x94/0x150
lock_is_held_type+0x140/0x200
___might_sleep+0x220/0x330
__might_fault+0x88/0x120
do_strncpy_from_user+0x108/0x2b0
strncpy_from_user+0x1d0/0x2a0
getname_flags+0x88/0x2c0
do_sys_openat2+0x2d4/0x5f0
do_sys_open+0xcc/0x140
system_call_exception+0x160/0x240
system_call_common+0xf0/0x27c
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
---
Changes:
v3:
* do not block/unblock if AMR was blocked
* reverted move of AMR_KUAP_***
* added pr_warn
v2:
* fixed compile on hash
* moved get/set to arch_local_irq_restore
* block KUAP before replaying
---
This is an example:
------------[ cut here ]------------
Bug: Read fault blocked by AMR!
WARNING: CPU: 0 PID: 1603 at /home/aik/p/kernel/arch/powerpc/include/asm/book3s/64/kup-radix.h:145 __do_page_fau
Modules linked in:
CPU: 0 PID: 1603 Comm: amr Not tainted 5.10.0-rc6_v5.10-rc6_a+fstn1 #24
NIP: c00000000009ece8 LR: c00000000009ece4 CTR: 0000000000000000
REGS: c00000000dc63560 TRAP: 0700 Not tainted (5.10.0-rc6_v5.10-rc6_a+fstn1)
MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 28002888 XER: 20040000
CFAR: c0000000001fa928 IRQMASK: 1
GPR00: c00000000009ece4 c00000000dc637f0 c000000002397600 000000000000001f
GPR04: c0000000020eb318 0000000000000000 c00000000dc63494 0000000000000027
GPR08: c00000007fe4de68 c00000000dfe9180 0000000000000000 0000000000000001
GPR12: 0000000000002000 c0000000030a0000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 bfffffffffffffff
GPR20: 0000000000000000 c0000000134a4020 c0000000019c2218 0000000000000fe0
GPR24: 0000000000000000 0000000000000000 c00000000d106200 0000000040000000
GPR28: 0000000000000000 0000000000000300 c00000000dc63910 c000000001946730
NIP [c00000000009ece8] __do_page_fault+0xb38/0xde0
LR [c00000000009ece4] __do_page_fault+0xb34/0xde0
Call Trace:
[c00000000dc637f0] [c00000000009ece4] __do_page_fault+0xb34/0xde0 (unreliable)
[c00000000dc638a0] [c00000000000c968] handle_page_fault+0x10/0x2c
--- interrupt: 300 at strncpy_from_user+0x290/0x440
LR = strncpy_from_user+0x284/0x440
[c00000000dc63ba0] [c000000000c3dcb0] strncpy_from_user+0x2f0/0x440 (unreliable)
[c00000000dc63c30] [c00000000068b888] getname_flags+0x88/0x2c0
[c00000000dc63c90] [c000000000662a44] do_sys_openat2+0x2d4/0x5f0
[c00000000dc63d30] [c00000000066560c] do_sys_open+0xcc/0x140
[c00000000dc63dc0] [c000000000045e10] system_call_exception+0x160/0x240
[c00000000dc63e20] [c00000000000da60] system_call_common+0xf0/0x27c
Instruction dump:
409c0048 3fe2ff5b 3bfff128 fac10060 fae10068 482f7a85 60000000 3c62ff5b
7fe4fb78 3863f250 4815bbd9 60000000 <0fe00000> 3c62ff5b 3863f2b8 4815c8b5
irq event stamp: 254
hardirqs last enabled at (253): [<c000000000019550>] arch_local_irq_restore+0xa0/0x150
hardirqs last disabled at (254): [<c000000000008a10>] data_access_common_virt+0x1b0/0x1d0
softirqs last enabled at (0): [<c0000000001f6d5c>] copy_process+0x78c/0x2120
softirqs last disabled at (0): [<0000000000000000>] 0x0
---[ end trace ba98aec5151f3aeb ]---
---
arch/powerpc/kernel/irq.c | 27 ++++++++++++++++++++++++++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index cc7a6271b6b4..592abc798826 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -269,6 +269,23 @@ void replay_soft_interrupts(void)
}
}
+#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_KUAP)
+static inline void replay_soft_interrupts_irqrestore(void)
+{
+ unsigned long kuap_state = get_kuap();
+
+ if (kuap_state != AMR_KUAP_BLOCKED)
+ set_kuap(AMR_KUAP_BLOCKED);
+
+ replay_soft_interrupts();
+
+ if (kuap_state != AMR_KUAP_BLOCKED)
+ set_kuap(kuap_state);
+}
+#else
+#define replay_soft_interrupts_irqrestore() replay_soft_interrupts()
+#endif
+
notrace void arch_local_irq_restore(unsigned long mask)
{
unsigned char irq_happened;
@@ -278,6 +295,14 @@ notrace void arch_local_irq_restore(unsigned long mask)
if (mask)
return;
+ /*
+ * It fires if anything calls local_irq_enable or restore when
+ * KUAP is enabled, and the code handles that just fine by saving
+ * and re-locking AMR but we would like to remove those calls,
+ * hence the warning.
+ */
+ kuap_check_amr();
+
/*
* From this point onward, we can take interrupts, preempt,
* etc... unless we got hard-disabled. We check if an event
@@ -332,7 +357,7 @@ notrace void arch_local_irq_restore(unsigned long mask)
irq_soft_mask_set(IRQS_ALL_DISABLED);
trace_hardirqs_off();
- replay_soft_interrupts();
+ replay_soft_interrupts_irqrestore();
local_paca->irq_happened = 0;
trace_hardirqs_on();
--
2.17.1
^ permalink raw reply related
* Re: [RFC 11/20] mm/tlb: remove arch-specific tlb_start/end_vma()
From: Peter Zijlstra @ 2021-02-02 9:31 UTC (permalink / raw)
To: Nadav Amit
Cc: Andrea Arcangeli, linux-s390, X86 ML, Yu Zhao, Will Deacon,
Dave Hansen, LKML, linux-csky@vger.kernel.org, Linux-MM,
Nicholas Piggin, Andy Lutomirski, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <F1C67840-C62F-4583-8593-B621706034F6@vmware.com>
On Tue, Feb 02, 2021 at 07:20:55AM +0000, Nadav Amit wrote:
> Arm does not define tlb_end_vma, and consequently it flushes the TLB after
> each VMA. I suspect it is not intentional.
ARM is one of those that look at the VM_EXEC bit to explicitly flush
ITLB IIRC, so it has to.
^ permalink raw reply
* Re: [PATCH] powerpc/fault: fix wrong KUAP fault for IO_URING
From: Nicholas Piggin @ 2021-02-02 9:49 UTC (permalink / raw)
To: Aneesh Kumar K.V, Christophe Leroy, Michael Ellerman, Zorro Lang
Cc: Jens Axboe, linuxppc-dev
In-Reply-To: <e2dfb7ec-a4d4-579d-a79b-6709df6e9e50@linux.ibm.com>
Excerpts from Aneesh Kumar K.V's message of February 2, 2021 4:30 pm:
> On 2/2/21 11:50 AM, Christophe Leroy wrote:
>>
>>
>> Le 02/02/2021 à 07:16, Aneesh Kumar K.V a écrit :
>>> On 2/2/21 11:32 AM, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 02/02/2021 à 06:55, Aneesh Kumar K.V a écrit :
>>>>> Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> writes:
>>>>>
>>>>>> Nicholas Piggin <npiggin@gmail.com> writes:
>>>>>>
>>>>>>> Excerpts from Michael Ellerman's message of January 30, 2021 9:22 pm:
>>>>>>>> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>>>>>>>>> +Aneesh
>>>>>>>>>
>>>>>>>>> Le 29/01/2021 à 07:52, Zorro Lang a écrit :
>>>>>>>> ..
>>>>>>>>>> [ 96.200296] ------------[ cut here ]------------
>>>>>>>>>> [ 96.200304] Bug: Read fault blocked by KUAP!
>>>>>>>>>> [ 96.200309] WARNING: CPU: 3 PID: 1876 at
>>>>>>>>>> arch/powerpc/mm/fault.c:229 bad_kernel_fault+0x180/0x310
>>>>>>>>>
>>>>>>>>>> [ 96.200734] NIP [c000000000849424]
>>>>>>>>>> fault_in_pages_readable+0x104/0x350
>>>>>>>>>> [ 96.200741] LR [c00000000084952c]
>>>>>>>>>> fault_in_pages_readable+0x20c/0x350
>>>>>>>>>> [ 96.200747] --- interrupt: 300
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Problem happens in a section where userspace access is supposed
>>>>>>>>> to be granted, so the patch you
>>>>>>>>> proposed is definitely not the right fix.
>>>>>>>>>
>>>>>>>>> c000000000849408: 2c 01 00 4c isync
>>>>>>>>> c00000000084940c: a6 03 3d 7d mtspr 29,r9 <== granting
>>>>>>>>> userspace access permission
>>>>>>>>> c000000000849410: 2c 01 00 4c isync
>>>>>>>>> c000000000849414: 00 00 36 e9 ld r9,0(r22)
>>>>>>>>> c000000000849418: 20 00 29 81 lwz r9,32(r9)
>>>>>>>>> c00000000084941c: 00 02 29 71 andi. r9,r9,512
>>>>>>>>> c000000000849420: 78 d3 5e 7f mr r30,r26
>>>>>>>>> ==> c000000000849424: 00 00 bf 8b lbz r29,0(r31) <==
>>>>>>>>> accessing userspace
>>>>>>>>> c000000000849428: 10 00 82 41 beq c000000000849438
>>>>>>>>> <fault_in_pages_readable+0x118>
>>>>>>>>> c00000000084942c: 2c 01 00 4c isync
>>>>>>>>> c000000000849430: a6 03 bd 7e mtspr 29,r21 <==
>>>>>>>>> clearing userspace access permission
>>>>>>>>> c000000000849434: 2c 01 00 4c isync
>>>>>>>>>
>>>>>>>>> My first guess is that the problem is linked to the following
>>>>>>>>> function, see the comment
>>>>>>>>>
>>>>>>>>> /*
>>>>>>>>> * For kernel thread that doesn't have thread.regs return
>>>>>>>>> * default AMR/IAMR values.
>>>>>>>>> */
>>>>>>>>> static inline u64 current_thread_amr(void)
>>>>>>>>> {
>>>>>>>>> if (current->thread.regs)
>>>>>>>>> return current->thread.regs->amr;
>>>>>>>>> return AMR_KUAP_BLOCKED;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Above function was introduced by commit 48a8ab4eeb82
>>>>>>>>> ("powerpc/book3s64/pkeys: Don't update SPRN_AMR
>>>>>>>>> when in kernel mode")
>>>>>>>>
>>>>>>>> Yeah that's a bit of a curly one.
>>>>>>>>
>>>>>>>> At some point io_uring did kthread_use_mm(), which is supposed to
>>>>>>>> mean
>>>>>>>> the kthread can operate on behalf of the original process that
>>>>>>>> submitted
>>>>>>>> the IO.
>>>>>>>>
>>>>>>>> But because KUAP is implemented using memory protection keys, it
>>>>>>>> depends
>>>>>>>> on the value of the AMR register, which is not part of the mm,
>>>>>>>> it's in
>>>>>>>> thread.regs->amr.
>>>>>>>>
>>>>>>>> And what's worse by the time we're in kthread_use_mm() we no
>>>>>>>> longer have
>>>>>>>> access to the thread.regs->amr of the original process that
>>>>>>>> submitted
>>>>>>>> the IO.
>>>>>>>>
>>>>>>>> We also can't simply move the AMR into the mm, precisely because
>>>>>>>> it's
>>>>>>>> per thread, not per mm.
>>>>>>>>
>>>>>>>> So TBH I don't know how we're going to fix this.
>>>>>>>>
>>>>>>>> I guess we could return AMR=unblocked for kernel threads, but that's
>>>>>>>> arguably a bug because it allows a process to circumvent memory
>>>>>>>> keys by
>>>>>>>> asking the kernel to do the access.
>>>>>>>
>>>>>>> We shouldn't need to inherit AMR should we? We only need it to be
>>>>>>> locked
>>>>>>> for kernel threads until it's explicitly unlocked -- nothing mm
>>>>>>> specific
>>>>>>> there. I think current_thread_amr could return 0 for kernel
>>>>>>> threads? Or
>>>>>>> I would even avoid using that function for allow_user_access and open
>>>>>>> code the kthread case and remove it from current_thread_amr().
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Nick
>>>>>>
>>>>>
>>>>> updated one
>>>>>
>>>>> From 8fdb0680f983940d61f91da8252b13c8d3e8ebee Mon Sep 17 00:00:00 2001
>>>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
>>>>> Date: Tue, 2 Feb 2021 09:23:38 +0530
>>>>> Subject: [PATCH v2] powerpc/kuap: Allow kernel thread to access
>>>>> userspace
>>>>> after kthread_use_mm
>>>>>
>>>>> This fix the bad fault reported by KUAP when io_wqe_worker access
>>>>> userspace.
>>>>>
>>>>> Bug: Read fault blocked by KUAP!
>>>>> WARNING: CPU: 1 PID: 101841 at arch/powerpc/mm/fault.c:229
>>>>> __do_page_fault+0x6b4/0xcd0
>>>>> NIP [c00000000009e7e4] __do_page_fault+0x6b4/0xcd0
>>>>> LR [c00000000009e7e0] __do_page_fault+0x6b0/0xcd0
>>>>> ..........
>>>>> Call Trace:
>>>>> [c000000016367330] [c00000000009e7e0] __do_page_fault+0x6b0/0xcd0
>>>>> (unreliable)
>>>>> [c0000000163673e0] [c00000000009ee3c] do_page_fault+0x3c/0x120
>>>>> [c000000016367430] [c00000000000c848] handle_page_fault+0x10/0x2c
>>>>> --- interrupt: 300 at iov_iter_fault_in_readable+0x148/0x6f0
>>>>> ..........
>>>>> NIP [c0000000008e8228] iov_iter_fault_in_readable+0x148/0x6f0
>>>>> LR [c0000000008e834c] iov_iter_fault_in_readable+0x26c/0x6f0
>>>>> interrupt: 300
>>>>> [c0000000163677e0] [c0000000007154a0] iomap_write_actor+0xc0/0x280
>>>>> [c000000016367880] [c00000000070fc94] iomap_apply+0x1c4/0x780
>>>>> [c000000016367990] [c000000000710330]
>>>>> iomap_file_buffered_write+0xa0/0x120
>>>>> [c0000000163679e0] [c00800000040791c]
>>>>> xfs_file_buffered_aio_write+0x314/0x5e0 [xfs]
>>>>> [c000000016367a90] [c0000000006d74bc] io_write+0x10c/0x460
>>>>> [c000000016367bb0] [c0000000006d80e4] io_issue_sqe+0x8d4/0x1200
>>>>> [c000000016367c70] [c0000000006d8ad0] io_wq_submit_work+0xc0/0x250
>>>>> [c000000016367cb0] [c0000000006e2578]
>>>>> io_worker_handle_work+0x498/0x800
>>>>> [c000000016367d40] [c0000000006e2cdc] io_wqe_worker+0x3fc/0x4f0
>>>>> [c000000016367da0] [c0000000001cb0a4] kthread+0x1c4/0x1d0
>>>>> [c000000016367e10] [c00000000000dbf0]
>>>>> ret_from_kernel_thread+0x5c/0x6c
>>>>>
>>>>> The kernel consider thread AMR value for kernel thread to be
>>>>> AMR_KUAP_BLOCKED. Hence access to userspace is denied. This
>>>>> of course not correct and we should allow userspace access after
>>>>> kthread_use_mm(). To be precise, kthread_use_mm() should inherit the
>>>>> AMR value of the operating address space. But, the AMR value is
>>>>> thread-specific and we inherit the address space and not thread
>>>>> access restrictions. Because of this ignore AMR value when accessing
>>>>> userspace via kernel thread.
>>>>>
>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>>>> ---
>>>>> Changes from v1:
>>>>> * Address review feedback from Nick
>>>>>
>>>>> arch/powerpc/include/asm/book3s/64/kup.h | 8 +++++++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> b/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> index f50f72e535aa..95f4df99249e 100644
>>>>> --- a/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> +++ b/arch/powerpc/include/asm/book3s/64/kup.h
>>>>> @@ -384,7 +384,13 @@ static __always_inline void
>>>>> allow_user_access(void __user *to, const void __user
>>>>> // This is written so we can resolve to a single case at build
>>>>> time
>>>>> BUILD_BUG_ON(!__builtin_constant_p(dir));
>>>>> - if (mmu_has_feature(MMU_FTR_PKEY))
>>>>> + /*
>>>>> + * if it is a kthread that did kthread_use_mm() don't
>>>>> + * use current_thread_amr().
>>>>
>>>> According to include/linux/sched.h, PF_KTHREAD means /* I am a kernel
>>>> thread */
>>>> It doesn't seem to be related to kthread_use_mm()
>>>
>>> That should be a sufficient check here. if we did reach here without
>>> calling kthread_user_mm, we will crash on access because we don't have
>>> a mm attached to the current process. a kernel thread with
>>> kthread_use_mm has
>>
>> Ok but then the comment doesn't match the check.
>
>
> I was trying to be explict in the comment that we expect the thread to
> have done kthread_use_mm().
I would avoid making it sound conditional. There is no way for a kernel
thread to ever access user without having done so.
/*
* Kernel threads may access user mm with kthread_use_mm() but
* can't use current_thread_amr because they have thread.regs==NULL,
* but they have no pkeys.
*/
>
>>
>> And also the comment in current_thread_amr() is then misleading.
>>
>> Why not do the current->flags & PF_KTHREAD check in current_thread_amr()
>> and return 0 in that case instead of BLOCKED ?
>
> In my view currrent_thread_amr() is more generic and we want to be
> explicit there that a kernel thread AMR is KUAP_BLOCKED. Only when we
> call allow user access, we relax the AMR value.
current_thread_amr() shouldn't be used by kernel threads ever
(after the patch). It's just confusing. The user access or the
check could have a test and warning for !current->mm if there
is a concern about it (maybe there already is one somehwere).
Thanks,
Nick
^ permalink raw reply
* Re: [RFC 11/20] mm/tlb: remove arch-specific tlb_start/end_vma()
From: Nadav Amit @ 2021-02-02 9:54 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrea Arcangeli, linux-s390, X86 ML, Yu Zhao, Will Deacon,
Dave Hansen, LKML, linux-csky@vger.kernel.org, Linux-MM,
Nicholas Piggin, Andy Lutomirski, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <YBkb8yKSUKTPJvxk@hirez.programming.kicks-ass.net>
> On Feb 2, 2021, at 1:31 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Tue, Feb 02, 2021 at 07:20:55AM +0000, Nadav Amit wrote:
>> Arm does not define tlb_end_vma, and consequently it flushes the TLB after
>> each VMA. I suspect it is not intentional.
>
> ARM is one of those that look at the VM_EXEC bit to explicitly flush
> ITLB IIRC, so it has to.
Hmm… I don’t think Arm is doing that. At least arm64 does not use the
default tlb_flush(), and it does not seem to consider VM_EXEC (at least in
this path):
static inline void tlb_flush(struct mmu_gather *tlb)
{
struct vm_area_struct vma = TLB_FLUSH_VMA(tlb->mm, 0);
bool last_level = !tlb->freed_tables;
unsigned long stride = tlb_get_unmap_size(tlb);
int tlb_level = tlb_get_level(tlb);
/*
* If we're tearing down the address space then we only care about
* invalidating the walk-cache, since the ASID allocator won't
* reallocate our ASID without invalidating the entire TLB.
*/
if (tlb->mm_exiting) {
if (!last_level)
flush_tlb_mm(tlb->mm);
return;
}
__flush_tlb_range(&vma, tlb->start, tlb->end, stride,
last_level, tlb_level);
}
^ permalink raw reply
* Re: [PATCH v11 01/13] mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page
From: Nicholas Piggin @ 2021-02-02 10:22 UTC (permalink / raw)
To: Andrew Morton, Ding Tianhong, linux-mm
Cc: linux-arch, linux-kernel, Christoph Hellwig, Jonathan Cameron,
Rick Edgecombe, linuxppc-dev, Christoph Hellwig
In-Reply-To: <2dcbe2c9-c968-4895-fc43-c40dfe9f06d3@huawei.com>
Excerpts from Ding Tianhong's message of January 28, 2021 1:13 pm:
> On 2021/1/26 12:44, Nicholas Piggin wrote:
>> vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
>> Whether or not a vmap is huge depends on the architecture details,
>> alignments, boot options, etc., which the caller can not be expected
>> to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
>>
>> This change teaches vmalloc_to_page about larger pages, and returns
>> the struct page that corresponds to the offset within the large page.
>> This makes the API agnostic to mapping implementation details.
>>
>> [*] As explained by commit 029c54b095995 ("mm/vmalloc.c: huge-vmap:
>> fail gracefully on unexpected huge vmap mappings")
>>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> mm/vmalloc.c | 41 ++++++++++++++++++++++++++---------------
>> 1 file changed, 26 insertions(+), 15 deletions(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index e6f352bf0498..62372f9e0167 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -34,7 +34,7 @@
>> #include <linux/bitops.h>
>> #include <linux/rbtree_augmented.h>
>> #include <linux/overflow.h>
>> -
>> +#include <linux/pgtable.h>
>> #include <linux/uaccess.h>
>> #include <asm/tlbflush.h>
>> #include <asm/shmparam.h>
>> @@ -343,7 +343,9 @@ int is_vmalloc_or_module_addr(const void *x)
>> }
>>
>> /*
>> - * Walk a vmap address to the struct page it maps.
>> + * Walk a vmap address to the struct page it maps. Huge vmap mappings will
>> + * return the tail page that corresponds to the base page address, which
>> + * matches small vmap mappings.
>> */
>> struct page *vmalloc_to_page(const void *vmalloc_addr)
>> {
>> @@ -363,25 +365,33 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
>>
>> if (pgd_none(*pgd))
>> return NULL;
>> + if (WARN_ON_ONCE(pgd_leaf(*pgd)))
>> + return NULL; /* XXX: no allowance for huge pgd */
>> + if (WARN_ON_ONCE(pgd_bad(*pgd)))
>> + return NULL;
>> +
>> p4d = p4d_offset(pgd, addr);
>> if (p4d_none(*p4d))
>> return NULL;
>> - pud = pud_offset(p4d, addr);
>> + if (p4d_leaf(*p4d))
>> + return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
>> + if (WARN_ON_ONCE(p4d_bad(*p4d)))
>> + return NULL;
>>
>> - /*
>> - * Don't dereference bad PUD or PMD (below) entries. This will also
>> - * identify huge mappings, which we may encounter on architectures
>> - * that define CONFIG_HAVE_ARCH_HUGE_VMAP=y. Such regions will be
>> - * identified as vmalloc addresses by is_vmalloc_addr(), but are
>> - * not [unambiguously] associated with a struct page, so there is
>> - * no correct value to return for them.
>> - */
>> - WARN_ON_ONCE(pud_bad(*pud));
>> - if (pud_none(*pud) || pud_bad(*pud))
>> + pud = pud_offset(p4d, addr);
>> + if (pud_none(*pud))
>> + return NULL;
>> + if (pud_leaf(*pud))
>> + return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>
> Hi Nicho:
>
> /builds/1mzfdQzleCy69KZFb5qHNSEgabZ/mm/vmalloc.c: In function 'vmalloc_to_page':
> /builds/1mzfdQzleCy69KZFb5qHNSEgabZ/include/asm-generic/pgtable-nop4d-hack.h:48:27: error: implicit declaration of function 'pud_page'; did you mean 'put_page'? [-Werror=implicit-function-declaration]
> 48 | #define pgd_page(pgd) (pud_page((pud_t){ pgd }))
> | ^~~~~~~~
>
> the pug_page is not defined for aarch32 when enabling 2-level page config, it break the system building.
Hey thanks for finding that, not sure why that didn't trigger any CI.
Anyway newer kernels don't have the ptable-*-hack.h headers, but even so
it still breaks upstream. arm is using some hand-rolled 2-level folding
of its own (which is fair enough because most 32-bit archs were 2 level
at the time I added pgtable-nopud.h header).
This patch seems to at least make it build.
Thanks,
Nick
---
arch/arm/include/asm/pgtable-3level.h | 2 --
arch/arm/include/asm/pgtable.h | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 2b85d175e999..d4edab51a77c 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -186,8 +186,6 @@ static inline pte_t pte_mkspecial(pte_t pte)
#define pmd_write(pmd) (pmd_isclear((pmd), L_PMD_SECT_RDONLY))
#define pmd_dirty(pmd) (pmd_isset((pmd), L_PMD_SECT_DIRTY))
-#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
-#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
#define pmd_hugewillfault(pmd) (!pmd_young(pmd) || !pmd_write(pmd))
#define pmd_thp_or_huge(pmd) (pmd_huge(pmd) || pmd_trans_huge(pmd))
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index c02f24400369..d63a5bb6bd0c 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -166,6 +166,9 @@ extern struct page *empty_zero_page;
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
+#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
+#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
+
#define pmd_none(pmd) (!pmd_val(pmd))
static inline pte_t *pmd_page_vaddr(pmd_t pmd)
--
2.23.0
^ permalink raw reply related
* Re: [PATCH v7 42/42] powerpc/64s: power4 nap fixup in C
From: Michael Ellerman @ 2021-02-02 10:31 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Athira Rajeev, Nicholas Piggin
In-Reply-To: <20210130130852.2952424-43-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> There is no need for this to be in asm, use the new intrrupt entry wrapper.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/interrupt.h | 15 +++++++++
> arch/powerpc/include/asm/processor.h | 1 +
> arch/powerpc/include/asm/thread_info.h | 6 ++++
> arch/powerpc/kernel/exceptions-64s.S | 45 --------------------------
> arch/powerpc/kernel/idle_book3s.S | 4 +++
> 5 files changed, 26 insertions(+), 45 deletions(-)
Something in here is making my G5 not boot.
I don't know what the problem is because that machine is in the office,
and I am not, and it has no serial console.
I tried turning on pstore but it doesn't record anything :/
cheers
^ permalink raw reply
* Re: [PATCH 05/13] kallsyms: refactor {,module_}kallsyms_on_each_symbol
From: Miroslav Benes @ 2021-02-02 10:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Petr Mladek, Jiri Kosina, Andrew Donnellan, linux-kbuild,
David Airlie, Masahiro Yamada, Josh Poimboeuf, Maarten Lankhorst,
linux-kernel, Maxime Ripard, live-patching, Michal Marek,
Joe Lawrence, dri-devel, Thomas Zimmermann, Jessica Yu,
Frederic Barrat, Daniel Vetter, linuxppc-dev
In-Reply-To: <20210201162842.GB7276@lst.de>
On Mon, 1 Feb 2021, Christoph Hellwig wrote:
> On Mon, Feb 01, 2021 at 02:37:12PM +0100, Miroslav Benes wrote:
> > > > This change is not needed. (objname == NULL) means that we are
> > > > interested only in symbols in "vmlinux".
> > > >
> > > > module_kallsyms_on_each_symbol(klp_find_callback, &args)
> > > > will always fail when objname == NULL.
> > >
> > > I just tried to keep the old behavior. I can respin it with your
> > > recommended change noting the change in behavior, though.
> >
> > Yes, please. It would be cleaner that way.
>
> Let me know if this works for you:
>
> ---
> >From 18af41e88d088cfb8680d1669fcae2bc2ede5328 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Wed, 20 Jan 2021 16:23:16 +0100
> Subject: kallsyms: refactor {,module_}kallsyms_on_each_symbol
>
> Require an explicit call to module_kallsyms_on_each_symbol to look
> for symbols in modules instead of the call from kallsyms_on_each_symbol,
> and acquire module_mutex inside of module_kallsyms_on_each_symbol instead
> of leaving that up to the caller. Note that this slightly changes the
> behavior for the livepatch code in that the symbols from vmlinux are not
> iterated anymore if objname is set, but that actually is the desired
> behavior in this case.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Thanks Christoph
M
^ permalink raw reply
* Re: [RFC PATCH 3/6] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Peter Zijlstra @ 2021-02-02 10:47 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linux-mm, kaleshsingh, joel, akpm, linuxppc-dev
In-Reply-To: <20210202091116.196134-3-aneesh.kumar@linux.ibm.com>
On Tue, Feb 02, 2021 at 02:41:13PM +0530, Aneesh Kumar K.V wrote:
> pmd/pud_populate is the right interface to be used to set the respective
> page table entries. Some architectures do assume that set_pmd/pud_at
> can only be used to set a hugepage PTE. Since we are not setting up a hugepage
> PTE here, use the pmd/pud_populate interface.
Since you did the audit, it might be nice to record which architectures
that are. Also, how much work to fix them?
^ permalink raw reply
* Re: [RFC 11/20] mm/tlb: remove arch-specific tlb_start/end_vma()
From: Peter Zijlstra @ 2021-02-02 11:04 UTC (permalink / raw)
To: Nadav Amit
Cc: Andrea Arcangeli, linux-s390, X86 ML, Yu Zhao, Will Deacon,
Dave Hansen, LKML, linux-csky@vger.kernel.org, Linux-MM,
Nicholas Piggin, Andy Lutomirski, Andrew Morton, linuxppc-dev,
Thomas Gleixner
In-Reply-To: <9100B8AE-129A-4E13-8F01-7B9C14C98B4C@vmware.com>
On Tue, Feb 02, 2021 at 09:54:36AM +0000, Nadav Amit wrote:
> > On Feb 2, 2021, at 1:31 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Tue, Feb 02, 2021 at 07:20:55AM +0000, Nadav Amit wrote:
> >> Arm does not define tlb_end_vma, and consequently it flushes the TLB after
> >> each VMA. I suspect it is not intentional.
> >
> > ARM is one of those that look at the VM_EXEC bit to explicitly flush
> > ITLB IIRC, so it has to.
>
> Hmm… I don’t think Arm is doing that. At least arm64 does not use the
> default tlb_flush(), and it does not seem to consider VM_EXEC (at least in
> this path):
>
ARM != ARM64. ARM certainly does, but you're right, I don't think ARM64
does this.
^ permalink raw reply
* [PATCH v12 00/14] huge vmalloc mappings
From: Nicholas Piggin @ 2021-02-02 11:05 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: linux-arch, Ding Tianhong, linux-kernel, Nicholas Piggin,
Christoph Hellwig, Jonathan Cameron, Rick Edgecombe, linuxppc-dev
Should be getting close now. No doubt there will be a few more
things but I can do incremental fixes for small things if this gets
into -mm.
Thanks,
Nick
Since v11:
- ARM compile fix (patch 1)
- debug_vm_pgtable compile fix
Since v10:
- Fixed code style, most > 80 colums, tweak patch titles, etc [thanks Christoph]
- Made huge vmalloc code and data structure compile away if unselected
[Christoph]
- Archs only have to provide arch_vmap_p?d_supported for levels they
implement [Christoph]
Since v9:
- Fixed intermediate build breakage on x86-32 !PAE [thanks Ding]
- Fixed small page fallback case vm_struct double-free [thanks Ding]
Since v8:
- Fixed nommu compile.
- Added Kconfig option help text
- Added VM_NOHUGE which should help archs implement it [suggested by Rick]
Since v7:
- Rebase, added some acks, compile fix
- Removed "order=" from vmallocinfo, it's a bit confusing (nr_pages
is in small page size for compatibility).
- Added arch_vmap_pmd_supported() test before starting to allocate
the large page, rather than only testing it when doing the map, to
avoid unsupported configs trying to allocate huge pages for no
reason.
Since v6:
- Fixed a false positive warning introduced in patch 2, found by
kbuild test robot.
Since v5:
- Split arch changes out better and make the constant folding work
- Avoid most of the 80 column wrap, fix a reference to lib/ioremap.c
- Fix compile error on some archs
Since v4:
- Fixed an off-by-page-order bug in v4
- Several minor cleanups.
- Added page order to /proc/vmallocinfo
- Added hugepage to alloc_large_system_hage output.
- Made an architecture config option, powerpc only for now.
Since v3:
- Fixed an off-by-one bug in a loop
- Fix !CONFIG_HAVE_ARCH_HUGE_VMAP build fail
Nicholas Piggin (14):
ARM: mm: add missing pud_page define to 2-level page tables
mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in
vmalloc_to_page
mm: apply_to_pte_range warn and fail if a large pte is encountered
mm/vmalloc: rename vmap_*_range vmap_pages_*_range
mm/ioremap: rename ioremap_*_range to vmap_*_range
mm: HUGE_VMAP arch support cleanup
powerpc: inline huge vmap supported functions
arm64: inline huge vmap supported functions
x86: inline huge vmap supported functions
mm/vmalloc: provide fallback arch huge vmap support functions
mm: Move vmap_range from mm/ioremap.c to mm/vmalloc.c
mm/vmalloc: add vmap_range_noflush variant
mm/vmalloc: Hugepage vmalloc mappings
powerpc/64s/radix: Enable huge vmalloc mappings
.../admin-guide/kernel-parameters.txt | 2 +
arch/Kconfig | 11 +
arch/arm/include/asm/pgtable-3level.h | 2 -
arch/arm/include/asm/pgtable.h | 3 +
arch/arm64/include/asm/vmalloc.h | 24 +
arch/arm64/mm/mmu.c | 26 -
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/vmalloc.h | 20 +
arch/powerpc/kernel/module.c | 21 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 21 -
arch/x86/include/asm/vmalloc.h | 20 +
arch/x86/mm/ioremap.c | 19 -
arch/x86/mm/pgtable.c | 13 -
include/linux/io.h | 9 -
include/linux/vmalloc.h | 46 ++
init/main.c | 1 -
mm/debug_vm_pgtable.c | 4 +-
mm/ioremap.c | 225 +-------
mm/memory.c | 66 ++-
mm/page_alloc.c | 5 +-
mm/vmalloc.c | 484 +++++++++++++++---
21 files changed, 619 insertions(+), 404 deletions(-)
--
2.23.0
^ permalink raw reply
* [PATCH v12 01/14] ARM: mm: add missing pud_page define to 2-level page tables
From: Nicholas Piggin @ 2021-02-02 11:05 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: linux-arch, Ding Tianhong, linux-kernel, Nicholas Piggin,
Russell King, Christoph Hellwig, Jonathan Cameron, Rick Edgecombe,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210202110515.3575274-1-npiggin@gmail.com>
ARM uses its own PMD folding scheme which is missing pud_page which
should just pass through to pmd_page. Move this from the 3-level
page table to common header.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Ding Tianhong <dingtianhong@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/arm/include/asm/pgtable-3level.h | 2 --
arch/arm/include/asm/pgtable.h | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 2b85d175e999..d4edab51a77c 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -186,8 +186,6 @@ static inline pte_t pte_mkspecial(pte_t pte)
#define pmd_write(pmd) (pmd_isclear((pmd), L_PMD_SECT_RDONLY))
#define pmd_dirty(pmd) (pmd_isset((pmd), L_PMD_SECT_DIRTY))
-#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
-#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
#define pmd_hugewillfault(pmd) (!pmd_young(pmd) || !pmd_write(pmd))
#define pmd_thp_or_huge(pmd) (pmd_huge(pmd) || pmd_trans_huge(pmd))
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index c02f24400369..d63a5bb6bd0c 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -166,6 +166,9 @@ extern struct page *empty_zero_page;
extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
+#define pud_page(pud) pmd_page(__pmd(pud_val(pud)))
+#define pud_write(pud) pmd_write(__pmd(pud_val(pud)))
+
#define pmd_none(pmd) (!pmd_val(pmd))
static inline pte_t *pmd_page_vaddr(pmd_t pmd)
--
2.23.0
^ permalink raw reply related
* [PATCH v12 02/14] mm/vmalloc: fix HUGE_VMAP regression by enabling huge pages in vmalloc_to_page
From: Nicholas Piggin @ 2021-02-02 11:05 UTC (permalink / raw)
To: linux-mm, Andrew Morton
Cc: linux-arch, Miaohe Lin, Ding Tianhong, linux-kernel,
Nicholas Piggin, Christoph Hellwig, Jonathan Cameron,
Rick Edgecombe, linuxppc-dev, Christoph Hellwig
In-Reply-To: <20210202110515.3575274-1-npiggin@gmail.com>
vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
Whether or not a vmap is huge depends on the architecture details,
alignments, boot options, etc., which the caller can not be expected
to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
This change teaches vmalloc_to_page about larger pages, and returns
the struct page that corresponds to the offset within the large page.
This makes the API agnostic to mapping implementation details.
[*] As explained by commit 029c54b095995 ("mm/vmalloc.c: huge-vmap:
fail gracefully on unexpected huge vmap mappings")
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
mm/vmalloc.c | 41 ++++++++++++++++++++++++++---------------
1 file changed, 26 insertions(+), 15 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index e6f352bf0498..62372f9e0167 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -34,7 +34,7 @@
#include <linux/bitops.h>
#include <linux/rbtree_augmented.h>
#include <linux/overflow.h>
-
+#include <linux/pgtable.h>
#include <linux/uaccess.h>
#include <asm/tlbflush.h>
#include <asm/shmparam.h>
@@ -343,7 +343,9 @@ int is_vmalloc_or_module_addr(const void *x)
}
/*
- * Walk a vmap address to the struct page it maps.
+ * Walk a vmap address to the struct page it maps. Huge vmap mappings will
+ * return the tail page that corresponds to the base page address, which
+ * matches small vmap mappings.
*/
struct page *vmalloc_to_page(const void *vmalloc_addr)
{
@@ -363,25 +365,33 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
if (pgd_none(*pgd))
return NULL;
+ if (WARN_ON_ONCE(pgd_leaf(*pgd)))
+ return NULL; /* XXX: no allowance for huge pgd */
+ if (WARN_ON_ONCE(pgd_bad(*pgd)))
+ return NULL;
+
p4d = p4d_offset(pgd, addr);
if (p4d_none(*p4d))
return NULL;
- pud = pud_offset(p4d, addr);
+ if (p4d_leaf(*p4d))
+ return p4d_page(*p4d) + ((addr & ~P4D_MASK) >> PAGE_SHIFT);
+ if (WARN_ON_ONCE(p4d_bad(*p4d)))
+ return NULL;
- /*
- * Don't dereference bad PUD or PMD (below) entries. This will also
- * identify huge mappings, which we may encounter on architectures
- * that define CONFIG_HAVE_ARCH_HUGE_VMAP=y. Such regions will be
- * identified as vmalloc addresses by is_vmalloc_addr(), but are
- * not [unambiguously] associated with a struct page, so there is
- * no correct value to return for them.
- */
- WARN_ON_ONCE(pud_bad(*pud));
- if (pud_none(*pud) || pud_bad(*pud))
+ pud = pud_offset(p4d, addr);
+ if (pud_none(*pud))
+ return NULL;
+ if (pud_leaf(*pud))
+ return pud_page(*pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+ if (WARN_ON_ONCE(pud_bad(*pud)))
return NULL;
+
pmd = pmd_offset(pud, addr);
- WARN_ON_ONCE(pmd_bad(*pmd));
- if (pmd_none(*pmd) || pmd_bad(*pmd))
+ if (pmd_none(*pmd))
+ return NULL;
+ if (pmd_leaf(*pmd))
+ return pmd_page(*pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+ if (WARN_ON_ONCE(pmd_bad(*pmd)))
return NULL;
ptep = pte_offset_map(pmd, addr);
@@ -389,6 +399,7 @@ struct page *vmalloc_to_page(const void *vmalloc_addr)
if (pte_present(pte))
page = pte_page(pte);
pte_unmap(ptep);
+
return page;
}
EXPORT_SYMBOL(vmalloc_to_page);
--
2.23.0
^ permalink raw reply related
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