* [PATCH V3 0/8] sched: Remove unused TASK_SIZE_OF for all archs
From: guoren @ 2021-12-28 6:47 UTC (permalink / raw)
To: guoren, will, tglx, benh, arnd, mingo, peterz, juri.lelli,
christophe.leroy, hca
Cc: linux-s390, Guo Ren, x86, linux-kernel, sparclinux, linux-mips,
linux-riscv, linuxppc-dev, inux-parisc, linux-arm-kernel
From: Guo Ren <guoren@linux.alibaba.com>
This macro isn't used in Linux, now. Delete in include/linux/sched.h
and arch's include/asm. This would confuse people who are
implementing the COMPAT feature for architecture.
Changes in v3:
- Fixup Documentation/process/submitting-patches.rst, add sender
Signed-off-by.
Changes in v2:
- Add Arnd's comment in main patch
- Optimize coding convention with Christophe's advise
Guo Ren (8):
sched: Remove unused TASK_SIZE_OF
sched: x86: Remove unused TASK_SIZE_OF
sched: sparc: Remove unused TASK_SIZE_OF
sched: powerpc: Remove unused TASK_SIZE_OF
sched: s390: Remove unused TASK_SIZE_OF
sched: parisc: Remove unused TASK_SIZE_OF
sched: arm64: Remove unused TASK_SIZE_OF
sched: mips: Remove unused TASK_SIZE_OF
arch/arm64/include/asm/processor.h | 2 --
arch/mips/include/asm/processor.h | 3 ---
arch/parisc/include/asm/processor.h | 3 +--
arch/powerpc/include/asm/task_size_64.h | 6 +-----
arch/s390/include/asm/processor.h | 3 +--
arch/sparc/include/asm/processor_64.h | 3 ---
arch/x86/include/asm/page_64_types.h | 2 --
include/linux/sched.h | 4 ----
8 files changed, 3 insertions(+), 23 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [PATCH v2 2/2] mm: usercopy: Warn vmalloc/module address in check_heap_object()
From: Kefeng Wang @ 2021-12-28 4:51 UTC (permalink / raw)
To: Christophe Leroy, Kees Cook, Laura Abbott, Mark Rutland,
linux-mm@kvack.org, Andrew Morton, linux-kernel@vger.kernel.org,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org
Cc: Nicholas Piggin
In-Reply-To: <fadd9754-ab85-63ec-4d6a-c6490adb5d94@csgroup.eu>
On 2021/12/27 1:33, Christophe Leroy wrote:
>
> Le 25/12/2021 à 13:06, Kefeng Wang a écrit :
>> virt_addr_valid() could be insufficient to validate the virt addr
>> on some architecture, which could lead to potential BUG which has
>> been found on arm64/powerpc64.
>>
>> Let's add WARN_ON to check if the virt addr is passed virt_addr_valid()
>> but is a vmalloc/module address.
> I think that's the responsibility of the architecture and doesn't
> deserve a WARN_ON() in generic code.
>
> The generic code cannot check all what architectures do wrong.
>
> Eventually you can do some testing at startup, maybe with
> CONFIG_DEBUG_VM_PGTABLE, but I don't think we should have such
> verification in functions like check_heap_object()
Ok, we could find other better place to add a virt_to_valid() check
instead of this one.
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> mm/usercopy.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/usercopy.c b/mm/usercopy.c
>> index b3de3c4eefba..ce83e0b137dd 100644
>> --- a/mm/usercopy.c
>> +++ b/mm/usercopy.c
>> @@ -228,6 +228,8 @@ static inline void check_heap_object(const void *ptr, unsigned long n,
>> if (!virt_addr_valid(ptr))
>> return;
>>
>> + WARN_ON_ONCE(is_vmalloc_or_module_addr(ptr));
>> +
>> /*
>> * When CONFIG_HIGHMEM=y, kmap_to_page() will give either the
>> * highmem page or fallback to virt_to_page(). The following
^ permalink raw reply
* [powerpc:next-test 127/179] include/linux/compiler_types.h:335:45: error: call to '__compiletime_assert_34' declared with attribute error: BUILD_BUG failed
From: kernel test robot @ 2021-12-28 4:30 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev, kbuild-all
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: beeac538c366cd2828092adecd1edab28326c55b
commit: 0faf20a1ad1647c0fc0f5a367c71e5e84deaf899 [127/179] powerpc/64s/interrupt: Don't enable MSR[EE] in irq handlers unless perf is in use
config: powerpc-randconfig-r021-20211227 (https://download.01.org/0day-ci/archive/20211228/202112281204.Rr4j6o5h-lkp@intel.com/config)
compiler: powerpc-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/powerpc/linux.git/commit/?id=0faf20a1ad1647c0fc0f5a367c71e5e84deaf899
git remote add powerpc https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 0faf20a1ad1647c0fc0f5a367c71e5e84deaf899
# save the config file 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 errors (new ones prefixed by >>):
In file included from <command-line>:
arch/powerpc/include/asm/hw_irq.h: In function 'do_hard_irq_enable':
>> include/linux/compiler_types.h:335:45: error: call to '__compiletime_assert_34' declared with attribute error: BUILD_BUG failed
335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
include/linux/compiler_types.h:316:25: note: in definition of macro '__compiletime_assert'
316 | prefix ## suffix(); \
| ^~~~~~
include/linux/compiler_types.h:335:9: note: in expansion of macro '_compiletime_assert'
335 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:59:21: note: in expansion of macro 'BUILD_BUG_ON_MSG'
59 | #define BUILD_BUG() BUILD_BUG_ON_MSG(1, "BUILD_BUG failed")
| ^~~~~~~~~~~~~~~~
arch/powerpc/include/asm/hw_irq.h:483:9: note: in expansion of macro 'BUILD_BUG'
483 | BUILD_BUG();
| ^~~~~~~~~
vim +/__compiletime_assert_34 +335 include/linux/compiler_types.h
eb5c2d4b45e3d2 Will Deacon 2020-07-21 321
eb5c2d4b45e3d2 Will Deacon 2020-07-21 322 #define _compiletime_assert(condition, msg, prefix, suffix) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 323 __compiletime_assert(condition, msg, prefix, suffix)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 324
eb5c2d4b45e3d2 Will Deacon 2020-07-21 325 /**
eb5c2d4b45e3d2 Will Deacon 2020-07-21 326 * compiletime_assert - break build and emit msg if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 327 * @condition: a compile-time constant condition to check
eb5c2d4b45e3d2 Will Deacon 2020-07-21 328 * @msg: a message to emit if condition is false
eb5c2d4b45e3d2 Will Deacon 2020-07-21 329 *
eb5c2d4b45e3d2 Will Deacon 2020-07-21 330 * In tradition of POSIX assert, this macro will break the build if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 331 * supplied condition is *false*, emitting the supplied error message if the
eb5c2d4b45e3d2 Will Deacon 2020-07-21 332 * compiler has support to do so.
eb5c2d4b45e3d2 Will Deacon 2020-07-21 333 */
eb5c2d4b45e3d2 Will Deacon 2020-07-21 334 #define compiletime_assert(condition, msg) \
eb5c2d4b45e3d2 Will Deacon 2020-07-21 @335 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
eb5c2d4b45e3d2 Will Deacon 2020-07-21 336
:::::: The code at line 335 was first introduced by commit
:::::: eb5c2d4b45e3d2d5d052ea6b8f1463976b1020d5 compiler.h: Move compiletime_assert() macros into compiler_types.h
:::::: TO: Will Deacon <will@kernel.org>
:::::: CC: Will Deacon <will@kernel.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: (No subject)
From: Kefeng Wang @ 2021-12-28 1:36 UTC (permalink / raw)
To: William Kucharski
Cc: x86@kernel.org, Will Deacon, linux-doc@vger.kernel.org,
Catalin Marinas, Jonathan Corbet, linux-kernel@vger.kernel.org,
Nicholas Piggin, linux-mm@kvack.org, Matthew Wilcox, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Paul Mackerras,
Andrew Morton, linuxppc-dev@lists.ozlabs.org, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <E2C9DE8E-F5D9-46E9-9298-B632A202B080@oracle.com>
On 2021/12/28 1:35, William Kucharski wrote:
> You should also fix the existing typo in the documentation (inline):
>
>> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>>
>> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
>> vmalloc mappings.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/kernel/module.c | 5 +++--
>> 3 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 7b2f900fd243..e3f9fd7ec106 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1639,7 +1639,7 @@
>> precedence over memory_hotplug.memmap_on_memory.
>>
>>
>> - hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> + hugevmalloc= [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
>> Format: { on | off }
>> Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
> "Reguires" should be "Requires."
Will fix, thanks.
>
>> @@ -3424,7 +3424,7 @@
>>
>> nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>>
>> - nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
>> + nohugevmalloc [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>>
>> nosmt [KNL,S390] Disable symmetric multithreading (SMT).
>> Equivalent to smt=1.
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 3bb0b67292b5..c34bbb4482b0 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -142,6 +142,7 @@ config ARM64
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_BITREVERSE
>> select HAVE_ARCH_COMPILER_H
>> + select HAVE_ARCH_HUGE_VMALLOC
>> select HAVE_ARCH_HUGE_VMAP
>> select HAVE_ARCH_JUMP_LABEL
>> select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
>> index 309a27553c87..af7b4cbace2b 100644
>> --- a/arch/arm64/kernel/module.c
>> +++ b/arch/arm64/kernel/module.c
>> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
>> module_alloc_end = MODULES_END;
>>
>> p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> - module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
>> + module_alloc_end, gfp_mask, PAGE_KERNEL,
>> + VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
>> NUMA_NO_NODE, __builtin_return_address(0));
>>
>> if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
>> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
>> */
>> p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
>> module_alloc_base + SZ_2G, GFP_KERNEL,
>> - PAGE_KERNEL, 0, NUMA_NO_NODE,
>> + PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
>> __builtin_return_address(0));
>>
>> if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
>> --
>> 2.26.2
>>
>>
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS beeac538c366cd2828092adecd1edab28326c55b
From: kernel test robot @ 2021-12-27 21:05 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: beeac538c366cd2828092adecd1edab28326c55b selftests/powerpc: Add a test of sigreturning to an unaligned address
elapsed time: 4084m
configs tested: 285
configs skipped: 3
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-20211225
mips cavium_octeon_defconfig
h8300 edosk2674_defconfig
powerpc fsp2_defconfig
riscv nommu_virt_defconfig
powerpc mpc834x_mds_defconfig
arc nsimosci_defconfig
mips rt305x_defconfig
powerpc ge_imp3a_defconfig
xtensa generic_kc705_defconfig
mips allyesconfig
sh microdev_defconfig
sparc sparc32_defconfig
m68k m5475evb_defconfig
mips jmr3927_defconfig
m68k m5275evb_defconfig
mips gpr_defconfig
powerpc allyesconfig
arm shannon_defconfig
arm moxart_defconfig
powerpc obs600_defconfig
arc haps_hs_defconfig
arm netwinder_defconfig
s390 zfcpdump_defconfig
arm cns3420vb_defconfig
x86_64 defconfig
sh ul2_defconfig
arm spear3xx_defconfig
sh se7751_defconfig
ia64 tiger_defconfig
arm rpc_defconfig
arm milbeaut_m10v_defconfig
sh apsh4ad0a_defconfig
powerpc mpc8272_ads_defconfig
arm vf610m4_defconfig
powerpc mpc7448_hpc2_defconfig
sh hp6xx_defconfig
powerpc stx_gp3_defconfig
powerpc ps3_defconfig
nios2 10m50_defconfig
arm lpc32xx_defconfig
riscv alldefconfig
arc axs101_defconfig
mips tb0226_defconfig
arc nsimosci_hs_defconfig
arm zeus_defconfig
csky defconfig
mips rb532_defconfig
arm s3c2410_defconfig
powerpc ppc44x_defconfig
arm neponset_defconfig
arm imote2_defconfig
riscv nommu_k210_defconfig
arm lpc18xx_defconfig
um x86_64_defconfig
arm mvebu_v7_defconfig
ia64 allmodconfig
sh ap325rxa_defconfig
powerpc amigaone_defconfig
powerpc mpc8540_ads_defconfig
sparc defconfig
arm spitz_defconfig
mips ip27_defconfig
powerpc mpc832x_rdb_defconfig
arm ixp4xx_defconfig
mips e55_defconfig
powerpc bluestone_defconfig
powerpc adder875_defconfig
sparc sparc64_defconfig
mips ip32_defconfig
arm multi_v5_defconfig
mips maltaaprp_defconfig
powerpc mpc834x_itx_defconfig
sh alldefconfig
mips decstation_defconfig
m68k bvme6000_defconfig
arm hisi_defconfig
m68k sun3_defconfig
arm mxs_defconfig
sparc alldefconfig
mips bcm47xx_defconfig
sh rsk7201_defconfig
powerpc mpc837x_rdb_defconfig
sh rsk7203_defconfig
mips loongson2k_defconfig
s390 alldefconfig
arm trizeps4_defconfig
h8300 h8s-sim_defconfig
powerpc acadia_defconfig
powerpc eiger_defconfig
arm dove_defconfig
arm viper_defconfig
sh kfr2r09_defconfig
powerpc mpc837x_mds_defconfig
sh sh7785lcr_32bit_defconfig
nds32 alldefconfig
sh kfr2r09-romimage_defconfig
arm sunxi_defconfig
mips ip22_defconfig
powerpc ppc64_defconfig
sh se7619_defconfig
riscv allmodconfig
powerpc lite5200b_defconfig
powerpc canyonlands_defconfig
arm vt8500_v6_v7_defconfig
sh secureedge5410_defconfig
powerpc redwood_defconfig
m68k m5307c3_defconfig
nds32 allnoconfig
powerpc mpc866_ads_defconfig
ia64 gensparse_defconfig
sh migor_defconfig
openrisc alldefconfig
h8300 h8300h-sim_defconfig
powerpc cell_defconfig
arm mps2_defconfig
sh lboxre2_defconfig
arm pleb_defconfig
powerpc holly_defconfig
mips capcella_defconfig
arm pxa255-idp_defconfig
arm cm_x300_defconfig
sh rts7751r2d1_defconfig
mips mtx1_defconfig
arm pcm027_defconfig
arm pxa3xx_defconfig
arm mmp2_defconfig
sh sh7785lcr_defconfig
m68k allyesconfig
powerpc chrp32_defconfig
powerpc cm5200_defconfig
h8300 defconfig
powerpc allnoconfig
mips cu1830-neo_defconfig
sh urquell_defconfig
arm sama5_defconfig
m68k m5208evb_defconfig
arc nsim_700_defconfig
arm xcep_defconfig
arm pxa168_defconfig
arm stm32_defconfig
arm tegra_defconfig
arm alldefconfig
powerpc mpc836x_rdk_defconfig
arm gemini_defconfig
arm omap2plus_defconfig
arm corgi_defconfig
sh rsk7264_defconfig
powerpc wii_defconfig
arc allyesconfig
xtensa audio_kc705_defconfig
sh sh7710voipgw_defconfig
arm orion5x_defconfig
powerpc ppa8548_defconfig
i386 alldefconfig
sh rsk7269_defconfig
powerpc linkstation_defconfig
powerpc64 defconfig
powerpc gamecube_defconfig
sh sh2007_defconfig
powerpc icon_defconfig
arm nhk8815_defconfig
parisc defconfig
powerpc asp8347_defconfig
arm mini2440_defconfig
sh shmin_defconfig
arm multi_v4t_defconfig
powerpc tqm5200_defconfig
arm s3c6400_defconfig
riscv allnoconfig
arm colibri_pxa270_defconfig
mips decstation_64_defconfig
arm clps711x_defconfig
powerpc pcm030_defconfig
arm collie_defconfig
powerpc makalu_defconfig
powerpc storcenter_defconfig
ia64 bigsur_defconfig
arm integrator_defconfig
riscv nommu_k210_sdcard_defconfig
mips mpc30x_defconfig
arm h5000_defconfig
arm imx_v4_v5_defconfig
microblaze mmu_defconfig
mips bcm63xx_defconfig
xtensa cadence_csp_defconfig
arm randconfig-c002-20211225
arm randconfig-c002-20211227
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
nios2 defconfig
nds32 defconfig
nios2 allyesconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allmodconfig
powerpc allmodconfig
x86_64 randconfig-a013-20211227
x86_64 randconfig-a014-20211227
x86_64 randconfig-a015-20211227
x86_64 randconfig-a011-20211227
x86_64 randconfig-a012-20211227
x86_64 randconfig-a016-20211227
x86_64 randconfig-a013-20211225
x86_64 randconfig-a014-20211225
x86_64 randconfig-a015-20211225
x86_64 randconfig-a011-20211225
x86_64 randconfig-a012-20211225
x86_64 randconfig-a016-20211225
i386 randconfig-a012-20211227
i386 randconfig-a011-20211227
i386 randconfig-a014-20211227
i386 randconfig-a016-20211227
i386 randconfig-a015-20211227
i386 randconfig-a013-20211227
i386 randconfig-a012-20211225
i386 randconfig-a011-20211225
i386 randconfig-a014-20211225
i386 randconfig-a016-20211225
i386 randconfig-a015-20211225
i386 randconfig-a013-20211225
arc randconfig-r043-20211225
s390 randconfig-r044-20211225
riscv randconfig-r042-20211225
arc randconfig-r043-20211227
s390 randconfig-r044-20211227
riscv randconfig-r042-20211227
riscv allyesconfig
riscv defconfig
riscv rv32_defconfig
x86_64 rhel-8.3-kselftests
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 kexec
clang tested configs:
riscv randconfig-c006-20211227
powerpc randconfig-c003-20211227
mips randconfig-c004-20211227
arm randconfig-c002-20211227
i386 randconfig-c001-20211227
x86_64 randconfig-c007-20211227
x86_64 randconfig-a003-20211227
x86_64 randconfig-a001-20211227
x86_64 randconfig-a005-20211227
x86_64 randconfig-a006-20211227
x86_64 randconfig-a004-20211227
x86_64 randconfig-a002-20211227
i386 randconfig-a006-20211227
i386 randconfig-a004-20211227
i386 randconfig-a002-20211227
i386 randconfig-a003-20211227
i386 randconfig-a005-20211227
i386 randconfig-a001-20211227
i386 randconfig-a002-20211225
i386 randconfig-a001-20211225
i386 randconfig-a003-20211225
i386 randconfig-a004-20211225
i386 randconfig-a006-20211225
i386 randconfig-a005-20211225
x86_64 randconfig-a003-20211225
x86_64 randconfig-a001-20211225
x86_64 randconfig-a005-20211225
x86_64 randconfig-a006-20211225
x86_64 randconfig-a004-20211225
x86_64 randconfig-a002-20211225
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: (No subject)
From: William Kucharski @ 2021-12-27 17:35 UTC (permalink / raw)
To: Kefeng Wang
Cc: x86@kernel.org, Will Deacon, linux-doc@vger.kernel.org,
Catalin Marinas, Jonathan Corbet, linux-kernel@vger.kernel.org,
Nicholas Piggin, linux-mm@kvack.org, Matthew Wilcox, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Paul Mackerras,
Andrew Morton, linuxppc-dev@lists.ozlabs.org, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20211227145903.187152-3-wangkefeng.wang@huawei.com>
You should also fix the existing typo in the documentation (inline):
> On Dec 27, 2021, at 07:49, Kefeng Wang <wangkefeng.wang@huawei.com> wrote:
>
> This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
> vmalloc mappings.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++--
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/module.c | 5 +++--
> 3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 7b2f900fd243..e3f9fd7ec106 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1639,7 +1639,7 @@
> precedence over memory_hotplug.memmap_on_memory.
>
>
> - hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> + hugevmalloc= [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
> Format: { on | off }
> Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
"Reguires" should be "Requires."
>
> @@ -3424,7 +3424,7 @@
>
> nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
>
> - nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
> + nohugevmalloc [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
>
> nosmt [KNL,S390] Disable symmetric multithreading (SMT).
> Equivalent to smt=1.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3bb0b67292b5..c34bbb4482b0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -142,6 +142,7 @@ config ARM64
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> select HAVE_ARCH_COMPILER_H
> + select HAVE_ARCH_HUGE_VMALLOC
> select HAVE_ARCH_HUGE_VMAP
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_JUMP_LABEL_RELATIVE
> diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
> index 309a27553c87..af7b4cbace2b 100644
> --- a/arch/arm64/kernel/module.c
> +++ b/arch/arm64/kernel/module.c
> @@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
> module_alloc_end = MODULES_END;
>
> p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> - module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
> + module_alloc_end, gfp_mask, PAGE_KERNEL,
> + VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
> NUMA_NO_NODE, __builtin_return_address(0));
>
> if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
> @@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
> */
> p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
> module_alloc_base + SZ_2G, GFP_KERNEL,
> - PAGE_KERNEL, 0, NUMA_NO_NODE,
> + PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
> __builtin_return_address(0));
>
> if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> --
> 2.26.2
>
>
^ permalink raw reply
* Re: [PATCH 2/3] KVM: PPC: Fix vmx/vsx mixup in mmio emulation
From: Fabiano Rosas @ 2021-12-27 17:28 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: aik, linuxppc-dev
In-Reply-To: <1640427087.r4g49fcnps.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Fabiano Rosas's message of December 24, 2021 7:15 am:
>> The MMIO emulation code for vector instructions is duplicated between
>> VSX and VMX. When emulating VMX we should check the VMX copy size
>> instead of the VSX one.
>>
>> Fixes: acc9eb9305fe ("KVM: PPC: Reimplement LOAD_VMX/STORE_VMX instruction ...")
>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>
> Good catch. AFAIKS handle_vmx_store needs the same treatment? If you
> agree then
Half the bug now, half the bug next year... haha I'll send a v2.
aside:
All this duplication is kind of annoying. I'm looking into what it would
take to have quadword instruction emulation here as well (Alexey caught
a bug with syskaller) and the code would be really similar. I see that
x86 has a more generic implementation that maybe we could take advantage
of. See "f78146b0f923 (KVM: Fix page-crossing MMIO)"
^ permalink raw reply
* [RFC 02/32] Kconfig: introduce HAS_IOPORT option and select it as necessary
From: Niklas Schnelle @ 2021-12-27 16:42 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Helgaas, John Garry, Nick Hu, Greentime Hu,
Vincent Chen, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
Dinh Nguyen, Chris Zankel, Karol Gugala, Jeff Dike,
Yoshinori Sato, Brian Cain, Heiko Carstens, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rich Felker, David S. Miller, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: linux-arch, linux-xtensa, linux-ia64, linux-parisc, linux-s390,
linux-pci, linux-sh, linux-kernel, linux-csky, linux-mips,
linux-m68k, openrisc, linux-alpha, sparclinux, linux-riscv,
linux-snps-arc, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20211227164317.4146918-1-schnelle@linux.ibm.com>
We introduce a new HAS_IOPORT Kconfig option to gate support for
I/O port access. In a future patch HAS_IOPORT=n will disable compilation
of the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces. On these platforms
inb()/outb() etc are currently just stubs in asm-generic/io.h which when
called will cause a NULL pointer access which some compilers actually
detect and warn about.
The dependencies on HAS_IOPORT in drivers as well as ifdefs for
HAS_IOPORT specific sections will be added in subsequent patches on
a per subsystem basis. Then a final patch will ifdef the I/O access
functions on HAS_IOPORT thus turning any use not gated by HAS_IOPORT
into a compile-time warning.
Link: https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1 +
arch/parisc/Kconfig | 1 +
arch/powerpc/Kconfig | 1 +
arch/riscv/Kconfig | 1 +
arch/sh/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
arch/x86/Kconfig | 1 +
drivers/bus/Kconfig | 2 +-
lib/Kconfig | 4 ++++
lib/Kconfig.kgdb | 1 +
17 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 4e87783c90ad..472a0c5e4c2f 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -28,6 +28,7 @@ config ALPHA
select AUDIT_ARCH
select GENERIC_CPU_VULNERABILITIES
select GENERIC_SMP_IDLE_THREAD
+ select HAS_IOPORT
select HAVE_ARCH_AUDITSYSCALL
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index b4ae6058902a..b3911ebbd237 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -27,6 +27,7 @@ config ARC
select GENERIC_PENDING_IRQ if SMP
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
+ select HAS_IOPORT
select HAVE_ARCH_KGDB
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARC_MMU_V4
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c2724d986fa0..605709b6eecb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -66,6 +66,7 @@ config ARM
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
select HARDIRQS_SW_RESEND
+ select HAS_IOPORT
select HAVE_ARCH_AUDITSYSCALL if AEABI && !OABI_COMPAT
select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c4207cf9bb17..a8b199a40c8f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -135,6 +135,7 @@ config ARM64
select GENERIC_GETTIMEOFDAY
select GENERIC_VDSO_TIME_NS
select HARDIRQS_SW_RESEND
+ select HAS_IOPORT
select HAVE_MOVE_PMD
select HAVE_MOVE_PUD
select HAVE_PCI
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 1e33666fa679..672aa2a88b19 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -24,6 +24,7 @@ config IA64
select PCI_DOMAINS if PCI
select PCI_MSI
select PCI_SYSCALL if PCI
+ select HAS_IOPORT
select HAVE_ASM_MODVERSIONS
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_EXIT_THREAD
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 0b50da08a9c5..926d97c33828 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -16,6 +16,7 @@ config M68K
select GENERIC_CPU_DEVICES
select GENERIC_IOMAP
select GENERIC_IRQ_SHOW
+ select HAS_IOPORT
select HAVE_AOUT if MMU
select HAVE_ASM_MODVERSIONS
select HAVE_DEBUG_BUGVERBOSE
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 59798e43cdb0..213ef2940079 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -21,6 +21,7 @@ config MICROBLAZE
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
select GENERIC_SCHED_CLOCK
+ select HAS_IOPORT if PCI
select HAVE_ARCH_HASH
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0215dc1529e9..87e6e7c29493 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -47,6 +47,7 @@ config MIPS
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select GUP_GET_PTE_LOW_HIGH if CPU_MIPS32 && PHYS_ADDR_T_64BIT
+ select HAS_IOPORT
select HAVE_ARCH_COMPILER_H
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB if MIPS_FP_SUPPORT
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 011dc32fdb4d..b352c6dbbead 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -43,6 +43,7 @@ config PARISC
select MODULES_USE_ELF_RELA
select CLONE_BACKWARDS
select TTY # Needed for pdc_cons.c
+ select HAS_IOPORT if PCI || EISA
select HAVE_DEBUG_STACKOVERFLOW
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HASH
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dea74d7717c0..d39ba34d839a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -185,6 +185,7 @@ config PPC
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL
select GENERIC_VDSO_TIME_NS
+ select HAS_IOPORT if PCI
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_HUGE_VMAP if PPC_RADIX_MMU || PPC_8xx
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 821252b65f89..b69cc86522fb 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -63,6 +63,7 @@ config RISCV
select GENERIC_SMP_IDLE_THREAD
select GENERIC_TIME_VSYSCALL if MMU && 64BIT
select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
+ select HAS_IOPORT if MMU
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 70afb30e0b32..334a52535379 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -24,6 +24,7 @@ config SUPERH
select GENERIC_SCHED_CLOCK
select GENERIC_SMP_IDLE_THREAD
select GUP_GET_PTE_LOW_HIGH if X2TLB
+ select HAS_IOPORT if HAS_IOPORT_MAP
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 66fc08646be5..728598673724 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -32,6 +32,7 @@ config SPARC
select GENERIC_IRQ_SHOW
select ARCH_WANT_IPC_PARSE_VERSION
select GENERIC_PCI_IOMAP
+ select HAS_IOPORT
select HAVE_NMI_WATCHDOG if SPARC64
select HAVE_CBPF_JIT if SPARC32
select HAVE_EBPF_JIT if SPARC64
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5c2ccb85f2ef..8d3cfd693559 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -153,6 +153,7 @@ config X86
select GUP_GET_PTE_LOW_HIGH if X86_PAE
select HARDIRQS_SW_RESEND
select HARDLOCKUP_CHECK_TIMESTAMP if X86_64
+ select HAS_IOPORT
select HAVE_ACPI_APEI if ACPI
select HAVE_ACPI_APEI_NMI if ACPI
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 3c68e174a113..a61285100224 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -81,7 +81,7 @@ config MOXTET
config HISILICON_LPC
bool "Support for ISA I/O space on HiSilicon Hip06/7"
depends on (ARM64 && ARCH_HISI) || (COMPILE_TEST && !ALPHA && !HEXAGON && !PARISC)
- depends on HAS_IOMEM
+ depends on HAS_IOPORT
select INDIRECT_PIO if ARM64
help
Driver to enable I/O access to devices attached to the Low Pin
diff --git a/lib/Kconfig b/lib/Kconfig
index 5e7165e6a346..e55746625762 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -95,6 +95,7 @@ config ARCH_USE_SYM_ANNOTATIONS
config INDIRECT_PIO
bool "Access I/O in non-MMIO mode"
depends on ARM64
+ depends on HAS_IOPORT
help
On some platforms where no separate I/O space exists, there are I/O
hosts which can not be accessed in MMIO mode. Using the logical PIO
@@ -486,6 +487,9 @@ config HAS_IOMEM
depends on !NO_IOMEM
default y
+config HAS_IOPORT
+ def_bool ISA || LEGACY_PCI
+
config HAS_IOPORT_MAP
bool
depends on HAS_IOMEM && !NO_IOPORT_MAP
diff --git a/lib/Kconfig.kgdb b/lib/Kconfig.kgdb
index 05dae05b6cc9..c68e4d9dcecb 100644
--- a/lib/Kconfig.kgdb
+++ b/lib/Kconfig.kgdb
@@ -121,6 +121,7 @@ config KDB_DEFAULT_ENABLE
config KDB_KEYBOARD
bool "KGDB_KDB: keyboard as input device"
+ depends on HAS_IOPORT
depends on VT && KGDB_KDB
default n
help
--
2.32.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] x86: Support huge vmalloc mappings
From: Dave Hansen @ 2021-12-27 15:56 UTC (permalink / raw)
To: Kefeng Wang, Jonathan Corbet, Andrew Morton, linuxppc-dev,
linux-doc, linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Matthew Wilcox, Catalin Marinas, Dave Hansen, Nicholas Piggin,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Paul Mackerras,
Thomas Gleixner, Will Deacon
In-Reply-To: <20211227145903.187152-4-wangkefeng.wang@huawei.com>
On 12/27/21 6:59 AM, Kefeng Wang wrote:
> This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
> support huge vmalloc mappings.
In general, this seems interesting and the diff is simple. But, I don't
see _any_ x86-specific data. I think the bare minimum here would be a
few kernel compiles and some 'perf stat' data for some TLB events.
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 95fa745e310a..6bf5cb7d876a 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
>
> p = __vmalloc_node_range(size, MODULE_ALIGN,
> MODULES_VADDR + get_module_load_offset(),
> - MODULES_END, gfp_mask,
> - PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
> + MODULES_END, gfp_mask, PAGE_KERNEL,
> + VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
> __builtin_return_address(0));
> if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
> vfree(p);
To figure out what's going on in this hunk, I had to look at the cover
letter (which I wasn't cc'd on). That's not great and it means that
somebody who stumbles upon this in the code is going to have a really
hard time figuring out what is going on. Cover letters don't make it
into git history.
This desperately needs a comment and some changelog material in *this*
patch.
But, even the description from the cover letter is sparse:
> There are some disadvantages about this feature[2], one of the main
> concerns is the possible memory fragmentation/waste in some scenarios,
> also archs must ensure that any arch specific vmalloc allocations that
> require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
> use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
That just says that x86 *needs* PAGE_SIZE allocations. But, what
happens if VM_NO_HUGE_VMAP is not passed (like it was in v1)? Will the
subsequent permission changes just fragment the 2M mapping?
^ permalink raw reply
* [PATCH v2 2/3] arm64: Support huge vmalloc mappings
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Kefeng Wang, Matthew Wilcox, Catalin Marinas, Dave Hansen,
Nicholas Piggin, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paul Mackerras, Thomas Gleixner, Will Deacon
In-Reply-To: <20211227145903.187152-1-wangkefeng.wang@huawei.com>
This patch select HAVE_ARCH_HUGE_VMALLOC to let arm64 support huge
vmalloc mappings.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/module.c | 5 +++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7b2f900fd243..e3f9fd7ec106 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
precedence over memory_hotplug.memmap_on_memory.
- hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+ hugevmalloc= [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
Format: { on | off }
Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
@@ -3424,7 +3424,7 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
- nohugevmalloc [PPC] Disable kernel huge vmalloc mappings.
+ nohugevmalloc [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3bb0b67292b5..c34bbb4482b0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -142,6 +142,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_COMPILER_H
+ select HAVE_ARCH_HUGE_VMALLOC
select HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index 309a27553c87..af7b4cbace2b 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -36,7 +36,8 @@ void *module_alloc(unsigned long size)
module_alloc_end = MODULES_END;
p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
- module_alloc_end, gfp_mask, PAGE_KERNEL, VM_DEFER_KMEMLEAK,
+ module_alloc_end, gfp_mask, PAGE_KERNEL,
+ VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP,
NUMA_NO_NODE, __builtin_return_address(0));
if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) &&
@@ -55,7 +56,7 @@ void *module_alloc(unsigned long size)
*/
p = __vmalloc_node_range(size, MODULE_ALIGN, module_alloc_base,
module_alloc_base + SZ_2G, GFP_KERNEL,
- PAGE_KERNEL, 0, NUMA_NO_NODE,
+ PAGE_KERNEL, VM_NO_HUGE_VMAP, NUMA_NO_NODE,
__builtin_return_address(0));
if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
--
2.26.2
^ permalink raw reply related
* [PATCH v2 3/3] x86: Support huge vmalloc mappings
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Kefeng Wang, Matthew Wilcox, Catalin Marinas, Dave Hansen,
Nicholas Piggin, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paul Mackerras, Thomas Gleixner, Will Deacon
In-Reply-To: <20211227145903.187152-1-wangkefeng.wang@huawei.com>
This patch select HAVE_ARCH_HUGE_VMALLOC to let X86_64 and X86_PAE
support huge vmalloc mappings.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
Documentation/admin-guide/kernel-parameters.txt | 4 ++--
arch/x86/Kconfig | 1 +
arch/x86/kernel/module.c | 4 ++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e3f9fd7ec106..ffce6591ae64 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1639,7 +1639,7 @@
precedence over memory_hotplug.memmap_on_memory.
- hugevmalloc= [KNL,PPC,ARM64] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+ hugevmalloc= [KNL,PPC,ARM64,X86] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
Format: { on | off }
Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
@@ -3424,7 +3424,7 @@
nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings.
- nohugevmalloc [KNL,PPC,ARM64] Disable kernel huge vmalloc mappings.
+ nohugevmalloc [KNL,PPC,ARM64,X86] Disable kernel huge vmalloc mappings.
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
Equivalent to smt=1.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ebe8fc76949a..f6bf6675bbe7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -157,6 +157,7 @@ config X86
select HAVE_ACPI_APEI_NMI if ACPI
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 95fa745e310a..6bf5cb7d876a 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -75,8 +75,8 @@ void *module_alloc(unsigned long size)
p = __vmalloc_node_range(size, MODULE_ALIGN,
MODULES_VADDR + get_module_load_offset(),
- MODULES_END, gfp_mask,
- PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE,
+ MODULES_END, gfp_mask, PAGE_KERNEL,
+ VM_DEFER_KMEMLEAK | VM_NO_HUGE_VMAP, NUMA_NO_NODE,
__builtin_return_address(0));
if (p && (kasan_module_alloc(p, size, gfp_mask) < 0)) {
vfree(p);
--
2.26.2
^ permalink raw reply related
* [PATCH v2 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Kefeng Wang, Matthew Wilcox, Catalin Marinas, Dave Hansen,
Nicholas Piggin, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paul Mackerras, Thomas Gleixner, Will Deacon
In-Reply-To: <20211227145903.187152-1-wangkefeng.wang@huawei.com>
Introduce HUGE_VMALLOC_DEFAULT_ENABLED and make it default y, this
let user to choose whether or not enable huge vmalloc mappings by
default.
Meanwhile, add new hugevmalloc=on/off parameter to enable or disable
this feature at boot time, nohugevmalloc is still supported and
equivalent to hugevmalloc=off.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
.../admin-guide/kernel-parameters.txt | 12 ++++++++++++
mm/Kconfig | 8 ++++++++
mm/vmalloc.c | 18 +++++++++++++++++-
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index a069d8fe2fee..7b2f900fd243 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1638,6 +1638,18 @@
If both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
+
+ hugevmalloc= [PPC] Reguires CONFIG_HAVE_ARCH_HUGE_VMALLOC
+ Format: { on | off }
+ Default set by CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED.
+
+ This parameter enables/disables kernel huge vmalloc
+ mappings at boot time.
+
+ on: Enable the feature
+ off: Disable the feature
+ Equivalent to: nohugevmalloc
+
hung_task_panic=
[KNL] Should the hung task detector generate panics.
Format: 0 | 1
diff --git a/mm/Kconfig b/mm/Kconfig
index a99bd499ef51..8d8a92f22905 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -262,6 +262,14 @@ config HUGETLB_PAGE_SIZE_VARIABLE
HUGETLB_PAGE_ORDER when there are multiple HugeTLB page sizes available
on a platform.
+config HUGE_VMALLOC_DEFAULT_ENABLED
+ bool "Enable huge vmalloc mappings by default"
+ default y
+ depends on HAVE_ARCH_HUGE_VMALLOC
+ help
+ Enable huge vmalloc mappings by default, this value could be overridden
+ by hugevmalloc=off|on.
+
config CONTIG_ALLOC
def_bool (MEMORY_ISOLATION && COMPACTION) || CMA
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 9bf838817a47..0d0f8deb5639 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -60,7 +60,7 @@ static const unsigned int ioremap_max_page_shift = PAGE_SHIFT;
#endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */
#ifdef CONFIG_HAVE_ARCH_HUGE_VMALLOC
-static bool __ro_after_init vmap_allow_huge = true;
+static bool __ro_after_init vmap_allow_huge = IS_ENABLED(CONFIG_HUGE_VMALLOC_DEFAULT_ENABLED);
static int __init set_nohugevmalloc(char *str)
{
@@ -68,6 +68,22 @@ static int __init set_nohugevmalloc(char *str)
return 0;
}
early_param("nohugevmalloc", set_nohugevmalloc);
+
+static int __init set_hugevmalloc(char *str)
+{
+ if (!str)
+ return -EINVAL;
+
+ if (!strcmp(str, "on"))
+ vmap_allow_huge = true;
+ else if (!strcmp(str, "off"))
+ vmap_allow_huge = false;
+ else
+ return -EINVAL;
+
+ return 0;
+}
+early_param("hugevmalloc", set_hugevmalloc);
#else /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
static const bool vmap_allow_huge = false;
#endif /* CONFIG_HAVE_ARCH_HUGE_VMALLOC */
--
2.26.2
^ permalink raw reply related
* [PATCH v2 0/3] mm: support huge vmalloc mapping on arm64/x86
From: Kefeng Wang @ 2021-12-27 14:59 UTC (permalink / raw)
To: Jonathan Corbet, Andrew Morton, linuxppc-dev, linux-doc,
linux-kernel, linux-mm, x86, linux-arm-kernel
Cc: Kefeng Wang, Matthew Wilcox, Catalin Marinas, Dave Hansen,
Nicholas Piggin, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paul Mackerras, Thomas Gleixner, Will Deacon
Huge vmalloc mappings is supported on PPC[1], but this feature should
be not only used on PPC, it could be used on arch support HAVE_ARCH_HUGE_VMAP
and PMD sized vmap mappings. this patchset is to enable this feature
on arm64/x86.
There are some disadvantages about this feature[2], one of the main
concerns is the possible memory fragmentation/waste in some scenarios,
also archs must ensure that any arch specific vmalloc allocations that
require PAGE_SIZE mappings(eg, module alloc with STRICT_MODULE_RWX)
use the VM_NO_HUGE_VMAP flag to inhibit larger mappings.
Based on the above considerations, we add the first patch is to let
user to control huge vmalloc mapping default behavior. Meanwhile,
add new kernel parameter hugevmalloc=on/off to enable/disable this
feature at boot time, nohugevmalloc parameter is still supported.
The later two patches to enable this feature on arm64/x86, select
HAVE_ARCH_HUGE_VMALLOC and mark VM_NO_HUGE_VMAP in arch's module_alloc().
This patchset based on next-20211224.
v2:
- Default y for HUGE_VMALLOC_DEFAULT_ENABLED, not only select it on PPC
- Fix copy/type error
- Mark VM_NO_HUGE_VMAP in module_alloc() on arm64/x86
[1] https://lore.kernel.org/linux-mm/20210317062402.533919-1-npiggin@gmail.com/
[2] https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/
Kefeng Wang (3):
mm: vmalloc: Let user to control huge vmalloc default behavior
arm64: Support huge vmalloc mappings
x86: Support huge vmalloc mappings
.../admin-guide/kernel-parameters.txt | 14 +++++++++++++-
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/module.c | 5 +++--
arch/x86/Kconfig | 1 +
arch/x86/kernel/module.c | 4 ++--
mm/Kconfig | 8 ++++++++
mm/vmalloc.c | 18 +++++++++++++++++-
7 files changed, 45 insertions(+), 6 deletions(-)
--
2.26.2
^ permalink raw reply
* [RFC PATCH 3/3] powerpc/pseries/vas: Use migration_in_progress to disable DLPAR
From: Haren Myneni @ 2021-12-27 11:00 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin, nathanl
In-Reply-To: <af4574e7553a632884a2f00fcb96bd82fa063fe9.camel@linux.ibm.com>
Before migration starts, all secondary CPUs will be offline which
can invoke VAS DLPAR event. So disable VAS DLPAR event with
migration_in_progress flag during suspend and enable after resume
operations.
The current partition migration implementation does not freeze the
user space and the user space can continue open VAS windows. So
when migration_in_progress flag is enabled, VAS open window
API returns -EBUSY.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
arch/powerpc/platforms/pseries/vas.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c
index d2d7202a4f4e..1a10c1904aaa 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -30,6 +30,7 @@ static bool copypaste_feat;
static struct vas_caps vascaps[VAS_MAX_FEAT_TYPE];
static DEFINE_MUTEX(vas_pseries_mutex);
+static bool migration_in_progress;
static long hcall_return_busy_check(long rc)
{
@@ -349,8 +350,11 @@ static struct vas_window *vas_allocate_window(int vas_id, u64 flags,
* same fault IRQ is not freed by the OS before.
*/
mutex_lock(&vas_pseries_mutex);
- rc = allocate_setup_window(txwin, (u64 *)&domain[0],
- cop_feat_caps->win_type);
+ if (migration_in_progress)
+ rc = -EBUSY;
+ else
+ rc = allocate_setup_window(txwin, (u64 *)&domain[0],
+ cop_feat_caps->win_type);
mutex_unlock(&vas_pseries_mutex);
if (rc)
goto out;
@@ -771,6 +775,9 @@ int vas_reconfig_capabilties(u8 type)
return -ENOMEM;
mutex_lock(&vas_pseries_mutex);
+ if (migration_in_progress)
+ goto out;
+
rc = h_query_vas_capabilities(H_QUERY_VAS_CAPABILITIES, vcaps->feat,
(u64)virt_to_phys(hv_caps));
if (rc)
@@ -866,6 +873,11 @@ static int vas_migrate_windows(bool suspend)
mutex_lock(&vas_pseries_mutex);
+ if (suspend)
+ migration_in_progress = true;
+ else
+ migration_in_progress = false;
+
for (i = 0; i < VAS_MAX_FEAT_TYPE; i++) {
vcaps = &vascaps[i];
caps = &vcaps->caps;
--
2.27.0
^ permalink raw reply related
* [RFC PATCH 2/3] powerpc/pseries/vas: Add VAS suspend/resume notifier
From: Haren Myneni @ 2021-12-27 10:59 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin, nathanl
In-Reply-To: <af4574e7553a632884a2f00fcb96bd82fa063fe9.camel@linux.ibm.com>
Since VAS windows belong to the VAS hardware resource, the
hypervisor expects the partition to close them on source partition
and reopen them after the partition migrated on the destination
machine.
This suspend/resume notifier invokes suspend operation before
and resume operation after migration. All active windows for
both default and QoS types will be closed during suspend and
reopen them during resume. During migration, the user space
should expect paste instruction failure if issues copy/paste
on these active windows.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
arch/powerpc/platforms/pseries/vas.c | 97 +++++++++++++++++++++++++++-
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c
index b9d1c0bac624..d2d7202a4f4e 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -16,6 +16,7 @@
#include <asm/machdep.h>
#include <asm/hvcall.h>
#include <asm/plpar_wrappers.h>
+#include <asm/pseries-suspend.h>
#include <asm/vas.h>
#include "vas.h"
@@ -845,6 +846,98 @@ static struct notifier_block pseries_vas_nb = {
.notifier_call = pseries_vas_notifier,
};
+/*
+ * For LPM, all windows have to be closed on the source partition
+ * before migration and reopen them on the destination partition
+ * after migration. So closing windows during suspend and
+ * reopen them during resume.
+ */
+static int vas_migrate_windows(bool suspend)
+{
+ struct hv_vas_cop_feat_caps *hv_caps;
+ struct vas_cop_feat_caps *caps;
+ int lpar_creds, new_creds = 0;
+ struct vas_caps *vcaps;
+ int i, rc = 0;
+
+ hv_caps = kmalloc(sizeof(*hv_caps), GFP_KERNEL);
+ if (!hv_caps)
+ return -ENOMEM;
+
+ mutex_lock(&vas_pseries_mutex);
+
+ for (i = 0; i < VAS_MAX_FEAT_TYPE; i++) {
+ vcaps = &vascaps[i];
+ caps = &vcaps->caps;
+ lpar_creds = atomic_read(&caps->target_creds);
+
+ rc = h_query_vas_capabilities(H_QUERY_VAS_CAPABILITIES, vcaps->feat,
+ (u64)virt_to_phys(hv_caps));
+ if (!rc) {
+ new_creds = be16_to_cpu(hv_caps->target_lpar_creds);
+ /*
+ * Should not happen. But incase print messages, close all
+ * windows in the list during suspend and reopen windows
+ * based on new lpar_creds on the destination system.
+ */
+ if (lpar_creds != new_creds) {
+ pr_err("%s: lpar creds: %d HV lpar creds: %d\n",
+ suspend ? "Suspend" : "Resume", lpar_creds,
+ new_creds);
+ pr_err("Used creds: %d, Active creds: %d\n",
+ atomic_read(&caps->used_creds),
+ vcaps->num_wins - vcaps->close_wins);
+ }
+ } else {
+ pr_err("%s: Get VAS capabilities failed with %d\n",
+ suspend ? "Suspend" : "Resume", rc);
+ /*
+ * We can not stop migration with the current lpm
+ * implementation. So continue closing all windows in the
+ * list (during suspend) and return without opending windows
+ * (during resume) if VAS capabilities HCALL failed.
+ */
+ if (!suspend)
+ goto out;
+ }
+
+ if (suspend)
+ rc = reconfig_close_windows(vcaps, vcaps->num_wins, true);
+ else {
+ atomic_set(&caps->target_creds, new_creds);
+ rc = reconfig_open_windows(vcaps, new_creds, true);
+ }
+
+ /*
+ * Ignore errors during suspend and return for resume.
+ */
+ if (rc && !suspend)
+ goto out;
+ }
+
+out:
+ mutex_unlock(&vas_pseries_mutex);
+ kfree(hv_caps);
+ return rc;
+}
+
+static int vas_migration_handler(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ if (action == PSERIES_RESUMING)
+ return vas_migrate_windows(false);
+ else
+ return vas_migrate_windows(true);
+
+}
+
+static struct pseries_suspend_handler vas_suspend_handler = {
+ .notifier_block = {
+ .notifier_call = vas_migration_handler,
+ },
+};
+
+
static int __init pseries_vas_init(void)
{
struct hv_vas_cop_feat_caps *hv_cop_caps;
@@ -901,8 +994,10 @@ static int __init pseries_vas_init(void)
}
/* Processors can be added/removed only on LPAR */
- if (copypaste_feat && firmware_has_feature(FW_FEATURE_LPAR))
+ if (copypaste_feat && firmware_has_feature(FW_FEATURE_LPAR)) {
of_reconfig_notifier_register(&pseries_vas_nb);
+ pseries_register_suspend_handler(&vas_suspend_handler);
+ }
pr_info("GZIP feature is available\n");
--
2.27.0
^ permalink raw reply related
* [RFC PATCH 1/3] powerpc/pseries/vas: Modify reconfig open/close functions for migration
From: Haren Myneni @ 2021-12-27 10:58 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin, nathanl
In-Reply-To: <af4574e7553a632884a2f00fcb96bd82fa063fe9.camel@linux.ibm.com>
VAS is a hardware engine stays on the chip. So when the partition
migrates, all VAS windows on the source system have to be closed
and reopen them on the destination after migration.
This patch make changes to the current reconfig_open/close_windows
functions to support migration:
- Sets the window status to VAS_WIN_MIGRATE_CLOSE when closes and
reopen windows with the same status during resume.
- Continue to close all windows even if deallocate HCALL failed
(should not happen) since no way to stop migration with the
current LPM implementation.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
arch/powerpc/include/asm/vas.h | 2 +
arch/powerpc/platforms/pseries/vas.c | 63 ++++++++++++++++++++++------
2 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/vas.h b/arch/powerpc/include/asm/vas.h
index 72d1df038b4b..8b28cd7aaedc 100644
--- a/arch/powerpc/include/asm/vas.h
+++ b/arch/powerpc/include/asm/vas.h
@@ -41,6 +41,8 @@
#define VAS_WIN_NO_CRED_CLOSE 0x4 /* Linux specific status when */
/* window is closed due to lost */
/* credit */
+#define VAS_WIN_MIGRATE_CLOSE 0x5 /* Linux status when window is */
+ /* closed due to migration */
/*
* Get/Set bit fields
*/
diff --git a/arch/powerpc/platforms/pseries/vas.c b/arch/powerpc/platforms/pseries/vas.c
index 169f0cccb166..b9d1c0bac624 100644
--- a/arch/powerpc/platforms/pseries/vas.c
+++ b/arch/powerpc/platforms/pseries/vas.c
@@ -449,11 +449,12 @@ static int vas_deallocate_window(struct vas_window *vwin)
mutex_lock(&vas_pseries_mutex);
/*
* VAS window is already closed in the hypervisor when
- * lost the credit. So just remove the entry from
- * the list, remove task references and free vas_window
+ * lost the credit or with migration. So just remove the entry
+ * from the list, remove task references and free vas_window
* struct.
*/
- if (win->vas_win.status != VAS_WIN_NO_CRED_CLOSE) {
+ if ((win->vas_win.status != VAS_WIN_NO_CRED_CLOSE) &&
+ (win->vas_win.status != VAS_WIN_MIGRATE_CLOSE)) {
rc = deallocate_free_window(win);
if (rc) {
mutex_unlock(&vas_pseries_mutex);
@@ -570,12 +571,14 @@ static int get_vas_capabilities(u8 feat, enum vas_cop_feat_type type,
* by setting the remapping to new paste address if the window is
* active.
*/
-static int reconfig_open_windows(struct vas_caps *vcaps, int creds)
+static int reconfig_open_windows(struct vas_caps *vcaps, int creds,
+ bool migrate)
{
long domain[PLPAR_HCALL9_BUFSIZE] = {VAS_DEFAULT_DOMAIN_ID};
struct vas_cop_feat_caps *caps = &vcaps->caps;
struct pseries_vas_window *win = NULL, *tmp;
int rc, mv_ents = 0;
+ int status;
/*
* Nothing to do if there are no closed windows.
@@ -594,8 +597,10 @@ static int reconfig_open_windows(struct vas_caps *vcaps, int creds)
* (dedicated). If 1 core is added, this LPAR can have 20 more
* credits. It means the kernel can reopen 20 windows. So move
* 20 entries in the VAS windows lost and reopen next 20 windows.
+ * For partition migration, reopen all windows that are closed
+ * during resume.
*/
- if (vcaps->close_wins > creds)
+ if ((vcaps->close_wins > creds) && !migrate)
mv_ents = vcaps->close_wins - creds;
list_for_each_entry_safe(win, tmp, &vcaps->list, win_list) {
@@ -605,11 +610,20 @@ static int reconfig_open_windows(struct vas_caps *vcaps, int creds)
mv_ents--;
}
+ /*
+ * Open windows if they are closed only with migration or
+ * DLPAR (lost credit) before.
+ */
+ if (migrate)
+ status = VAS_WIN_MIGRATE_CLOSE;
+ else
+ status = VAS_WIN_NO_CRED_CLOSE;
+
list_for_each_entry_safe_from(win, tmp, &vcaps->list, win_list) {
/*
* Nothing to do on this window if it is active.
*/
- if (win->vas_win.status != VAS_WIN_NO_CRED_CLOSE)
+ if (win->vas_win.status != status)
continue;
rc = allocate_setup_window(win, (u64 *)&domain[0],
@@ -652,17 +666,26 @@ static int reconfig_open_windows(struct vas_caps *vcaps, int creds)
* the user space to fall back to SW compression and manage with the
* existing windows.
*/
-static int reconfig_close_windows(struct vas_caps *vcap, int excess_creds)
+static int reconfig_close_windows(struct vas_caps *vcap, int excess_creds,
+ bool migrate)
{
struct pseries_vas_window *win, *tmp;
struct vas_user_win_ref *task_ref;
struct vm_area_struct *vma;
- int rc = 0;
+ int rc = 0, status;
+
+ if (migrate)
+ status = VAS_WIN_MIGRATE_CLOSE;
+ else
+ status = VAS_WIN_NO_CRED_CLOSE;
list_for_each_entry_safe(win, tmp, &vcap->list, win_list) {
/*
* This window is already closed due to lost credit
* before. Go for next window.
+ * For migration, nothing to do since this window
+ * closed for DLPAR and will be reopened even on
+ * the destination system with other DLPAR operation.
*/
if (win->vas_win.status == VAS_WIN_NO_CRED_CLOSE)
continue;
@@ -674,7 +697,7 @@ static int reconfig_close_windows(struct vas_caps *vcap, int excess_creds)
* Number of available credits are reduced, So select
* and close windows.
*/
- win->vas_win.status = VAS_WIN_NO_CRED_CLOSE;
+ win->vas_win.status = status;
mmap_write_lock(task_ref->mm);
/*
@@ -697,12 +720,24 @@ static int reconfig_close_windows(struct vas_caps *vcap, int excess_creds)
* later when the process issued with close(FD).
*/
rc = deallocate_free_window(win);
- if (rc)
+ /*
+ * This failure is from the hypervisor.
+ * No way to stop migration for these failures.
+ * So ignore error and continue closing other windows.
+ */
+ if (rc && !migrate)
return rc;
vcap->close_wins++;
- if (!--excess_creds)
+ /*
+ * For migration, do not depend on lpar_creds in case if
+ * mismatch with the hypervisor value (should not happen).
+ * So close all active windows in the list and will be
+ * reopened windows based on the new lpar_creds on the
+ * destination system during resume.
+ */
+ if (!migrate && !--excess_creds)
break;
}
@@ -757,7 +792,8 @@ int vas_reconfig_capabilties(u8 type)
* target, reopen windows if they are closed due to
* the previous DLPAR (core removal).
*/
- rc = reconfig_open_windows(vcaps, new_creds - lpar_creds);
+ rc = reconfig_open_windows(vcaps, new_creds - lpar_creds,
+ false);
} else {
/*
* # active windows is more than new LPAR available
@@ -765,7 +801,8 @@ int vas_reconfig_capabilties(u8 type)
*/
active_wins = vcaps->num_wins - vcaps->close_wins;
if (active_wins > new_creds)
- rc = reconfig_close_windows(vcaps, active_wins - new_creds);
+ rc = reconfig_close_windows(vcaps, active_wins - new_creds,
+ false);
}
out:
--
2.27.0
^ permalink raw reply related
* [RFC PATCH 0/3] powerpc/pseries/vas: VAS/NXGZIP support with LPM
From: Haren Myneni @ 2021-12-27 10:56 UTC (permalink / raw)
To: mpe, linuxppc-dev, npiggin, nathanl; +Cc: haren
Virtual Accelerator Switchboard (VAS) is an engine stays on the
chip. So all windows opened on a specific engine belongs to VAS
the chip. The hypervisor expects the partition to close all
active windows on the sources system and reopen them after
migration on the destination machine.
This patch series adds VAS support with the partition migration.
When the migration initiates, the VAS code gets suspend notifier
which closes all active windows and sets VAS_WIN_MIGRATE_CLOSE as
window status. Whereas receives resume notifier after migration
to reopen all windows which has VAS_WIN_MIGRATE_CLOSE status.
These patches depend on VAS/DLPAR support patch series
(https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-December/238331.html)
Also the suspend/resume notifier code is added in a separate patch
and will be posted later with the actual patches.
Haren Myneni (3):
powerpc/pseries/vas: Modify reconfig open/close functions for
migration
powerpc/pseries/vas: Add VAS suspend/resume notifier
powerpc/pseries/vas: Use migration_in_progress to disable DLPAR
arch/powerpc/include/asm/vas.h | 2 +
arch/powerpc/platforms/pseries/vas.c | 176 ++++++++++++++++++++++++---
2 files changed, 162 insertions(+), 16 deletions(-)
--
2.27.0
^ permalink raw reply
* Re: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
From: Kefeng Wang @ 2021-12-27 6:14 UTC (permalink / raw)
To: Matthew Wilcox
Cc: x86@kernel.org, Paul Mackerras, linux-doc@vger.kernel.org,
Catalin Marinas, Jonathan Corbet, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Will Deacon, Ingo Molnar, Dave Hansen,
Nicholas Piggin, H. Peter Anvin, Borislav Petkov, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <YckwuA8CWcQpQdGO@casper.infradead.org>
On 2021/12/27 11:19, Matthew Wilcox wrote:
> On Mon, Dec 27, 2021 at 09:44:24AM +0800, Kefeng Wang wrote:
>> On 2021/12/27 1:36, Christophe Leroy wrote:
>>> Le 26/12/2021 à 09:39, Kefeng Wang a écrit :
>>>> Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or
>>>> not enable huge vmalloc mappings by default, and this could make
>>>> more architectures to enable huge vmalloc mappings feature but
>>>> don't want to enable it by default.
>>>>
>>>> Add hugevmalloc=on/off parameter to enable or disable this feature
>>>> at boot time, nohugevmalloc is still supported and equivalent to
>>>> hugevmalloc=off.
>>> Is there a real added value to have the user be able to select that ?
>>>
>>> If the architecture supports it, is there any good reason to not use it ?
>> There are some disadvantages[1], one of the main concerns is the possible
>>
>> memory waste, we have backported this feature to our kernel 5.10, but our
>>
>> downstream in our some scenario(especially in embedded), they don't want
>>
>> it enabled by default, and others want it, this is why patch1 comes.
>>
>>> Why not just do like PPC and enable it by default ? Why should it be
>>> enabled by default on PPC but disabled by default on ARM64 and X86 ?
>> The PPC is default enabled, we don't changes this behavior.
>>
>> Maybe upstream is not care about this, as I said in cover-letter, if
>> arm64/x86
>>
>> don't want patch1, we could only just select config to enable it.
>>
>> Let's wait for more feedback.
> We should not have different defaults by architecture. Either we change
> the default for PPC, or x86 & arm should have the same default as PPC.
Ok, since HUGE_VMALLOC_DEFAULT_ENABLED is introduced, we could make it
default y, not only select it on PPC, then the ppc/arm64/x86 have same
default value.
And if someone don't want it, they could not enable this config.
Meanwhile hugevmalloc=on/off to make this feature to enable/disable at
boot time.
I will add some explanation and resend it, thanks.
> .
^ permalink raw reply
* Re: [PATCH] powerpc/sysdev/of_rtc: Fix possible memory leak in of_instantiate_rtc
From: He Ying @ 2021-12-27 3:33 UTC (permalink / raw)
To: mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20211103014717.162886-1-heying24@huawei.com>
Ping. Any ideas about this patch?
在 2021/11/3 9:47, He Ying 写道:
> If of_address_to_resource() in of_instantiate_rtc() fails, previously
> allocated memory res is not freed. Add missing kfree() for it.
>
> Signed-off-by: He Ying <heying24@huawei.com>
> ---
> arch/powerpc/sysdev/of_rtc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/sysdev/of_rtc.c b/arch/powerpc/sysdev/of_rtc.c
> index 1f408d34a6a7..23b896996c2f 100644
> --- a/arch/powerpc/sysdev/of_rtc.c
> +++ b/arch/powerpc/sysdev/of_rtc.c
> @@ -44,6 +44,7 @@ void __init of_instantiate_rtc(void)
> printk(KERN_ERR "OF RTC: Error "
> "translating resources for %pOF\n",
> node);
> + kfree(res);
> continue;
> }
>
^ permalink raw reply
* Re: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
From: Matthew Wilcox @ 2021-12-27 3:19 UTC (permalink / raw)
To: Kefeng Wang
Cc: x86@kernel.org, Paul Mackerras, linux-doc@vger.kernel.org,
Catalin Marinas, Jonathan Corbet, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Will Deacon, Ingo Molnar, Dave Hansen,
Nicholas Piggin, H. Peter Anvin, Borislav Petkov, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <c7037a3a-d0b1-6351-5e31-22be0d8e0e01@huawei.com>
On Mon, Dec 27, 2021 at 09:44:24AM +0800, Kefeng Wang wrote:
>
> On 2021/12/27 1:36, Christophe Leroy wrote:
> >
> > Le 26/12/2021 à 09:39, Kefeng Wang a écrit :
> > > Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or
> > > not enable huge vmalloc mappings by default, and this could make
> > > more architectures to enable huge vmalloc mappings feature but
> > > don't want to enable it by default.
> > >
> > > Add hugevmalloc=on/off parameter to enable or disable this feature
> > > at boot time, nohugevmalloc is still supported and equivalent to
> > > hugevmalloc=off.
> >
> > Is there a real added value to have the user be able to select that ?
> >
> > If the architecture supports it, is there any good reason to not use it ?
>
> There are some disadvantages[1], one of the main concerns is the possible
>
> memory waste, we have backported this feature to our kernel 5.10, but our
>
> downstream in our some scenario(especially in embedded), they don't want
>
> it enabled by default, and others want it, this is why patch1 comes.
>
> >
> > Why not just do like PPC and enable it by default ? Why should it be
> > enabled by default on PPC but disabled by default on ARM64 and X86 ?
>
> The PPC is default enabled, we don't changes this behavior.
>
> Maybe upstream is not care about this, as I said in cover-letter, if
> arm64/x86
>
> don't want patch1, we could only just select config to enable it.
>
> Let's wait for more feedback.
We should not have different defaults by architecture. Either we change
the default for PPC, or x86 & arm should have the same default as PPC.
^ permalink raw reply
* Re: [PATCH 1/3] mm: vmalloc: Let user to control huge vmalloc default behavior
From: Kefeng Wang @ 2021-12-27 1:44 UTC (permalink / raw)
To: Christophe Leroy, Jonathan Corbet, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Catalin Marinas, Dave Hansen, Nicholas Piggin, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Paul Mackerras, Thomas Gleixner,
Will Deacon
In-Reply-To: <6c4bd989-268e-5899-09a7-ac573bd8b4d9@csgroup.eu>
On 2021/12/27 1:36, Christophe Leroy wrote:
>
> Le 26/12/2021 à 09:39, Kefeng Wang a écrit :
>> Add HUGE_VMALLOC_DEFAULT_ENABLED to let user to choose whether or
>> not enable huge vmalloc mappings by default, and this could make
>> more architectures to enable huge vmalloc mappings feature but
>> don't want to enable it by default.
>>
>> Add hugevmalloc=on/off parameter to enable or disable this feature
>> at boot time, nohugevmalloc is still supported and equivalent to
>> hugevmalloc=off.
>
> Is there a real added value to have the user be able to select that ?
>
> If the architecture supports it, is there any good reason to not use it ?
There are some disadvantages[1], one of the main concerns is the possible
memory waste, we have backported this feature to our kernel 5.10, but our
downstream in our some scenario(especially in embedded), they don't want
it enabled by default, and others want it, this is why patch1 comes.
>
> Why not just do like PPC and enable it by default ? Why should it be
> enabled by default on PPC but disabled by default on ARM64 and X86 ?
The PPC is default enabled, we don't changes this behavior.
Maybe upstream is not care about this, as I said in cover-letter, if
arm64/x86
don't want patch1, we could only just select config to enable it.
Let's wait for more feedback.
Thanks.
[1]
https://lore.kernel.org/linux-mm/1616036421.amjz2efujj.astroid@bobo.none/
^ permalink raw reply
* Re: [PATCH] powerpc: dts: Remove "spidev" nodes
From: Michael Ellerman @ 2021-12-26 21:52 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, Rob Herring,
Michael Ellerman
Cc: devicetree, Mark Brown, linuxppc-dev, linux-kernel
In-Reply-To: <20211217221400.3667133-1-robh@kernel.org>
On Fri, 17 Dec 2021 16:14:00 -0600, Rob Herring wrote:
> "spidev" is not a real device, but a Linux implementation detail. It has
> never been documented either. The kernel has WARNed on the use of it for
> over 6 years. Time to remove its usage from the tree.
>
>
Applied to powerpc/next.
[1/1] powerpc: dts: Remove "spidev" nodes
https://git.kernel.org/powerpc/c/9cbbe6bae938dd335a5092b0ce41f88cb39ba40c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: fix spelling of "its"
From: Michael Ellerman @ 2021-12-26 21:52 UTC (permalink / raw)
To: Randy Dunlap, linuxppc-dev
In-Reply-To: <20211223003942.22098-1-rdunlap@infradead.org>
On Wed, 22 Dec 2021 16:39:42 -0800, Randy Dunlap wrote:
> Use the possessive "its" instead of the contraction of "it is" (it's).
>
>
Applied to powerpc/next.
[1/1] powerpc: fix spelling of "its"
https://git.kernel.org/powerpc/c/5b09250cca85ae6f91c9562cf1f5e5747de0a75d
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/64s/radix: Fix huge vmap false positive
From: Michael Ellerman @ 2021-12-26 21:52 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Daniel Axtens
In-Reply-To: <20211216103342.609192-1-npiggin@gmail.com>
On Thu, 16 Dec 2021 20:33:42 +1000, Nicholas Piggin wrote:
> pmd_huge() is defined to false when HUGETLB_PAGE is not configured, but
> the vmap code still installs huge PMDs. This leads to false bad PMD
> errors when vunmapping because it is not seen as a huge PTE, and the bad
> PMD check catches it. The end result may not be much more serious than
> some bad pmd warning messages, because the pmd_none_or_clear_bad() does
> what we wanted and clears the huge PTE anyway.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/64s/radix: Fix huge vmap false positive
https://git.kernel.org/powerpc/c/467ba14e1660b52a2f9338b484704c461bd23019
cheers
^ permalink raw reply
* Re: [PATCH v2 00/20] powerpc: Define eligible functions as __init
From: Michael Ellerman @ 2021-12-26 21:52 UTC (permalink / raw)
To: Nick Child, linuxppc-dev; +Cc: Nick Child, dja
In-Reply-To: <20211216220035.605465-1-nick.child@ibm.com>
On Thu, 16 Dec 2021 17:00:15 -0500, Nick Child wrote:
> This patchset focuses on redefining/declaring functions that could be
> labeled with the macro `__init`. From my understanding, an
> initialization function is one which is only needed during the initial
> phases of booting, after which it's resources can be freed. I figure
> that any function which is only called by other initialization
> functions may also be labeled as an initialization function. There are
> several (mostly static) functions which can and should be labeled as
> `__init`. I created some scripts to help identify these functions. It
> scans all functions defined in `arch/powerpc` and, if it is only called
> by functions with the `__init` attribute, it will go on to adjust the
> prototype and definition to include the `__init` declaration. This
> patchset hopes to solve related issue #282:
> https://github.com/linuxppc/issues/issues/282
>
> [...]
Applied to powerpc/next.
[01/20] powerpc/kernel: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/d276960d9296b6a9074795fe60a513abf8474e35
[02/20] powerpc/lib: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/ce0c6be9c69883df38e7631d1d7364b52f6db135
[03/20] powerpc/mm: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/c13f2b2bb5afd90f152c389c1c9245a0d43bce80
[04/20] powerpc/perf: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/c49f5d88ff0166ffa4e48ee8ce84d63719f346be
[05/20] powerpc/sysdev: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/6c552983d0e65a8c923dfacc4f69b694205672c1
[06/20] powerpc/xmon: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/456e8eb324a47573b377f7041f4c038fac403f86
[07/20] powerpc/cell: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/7c1ab16b2d035c6bc3b6b6980ab7e72f547edc45
[08/20] powerpc/chrp: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/d3aa3c5edf0cb7ac0b0b5b0d144bba60b0ee77da
[09/20] powerpc/pasemi: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/e37e06af9b0d6b7828159455d33f8ef45c456460
[10/20] powerpc/powermac: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/b346f57100e9417f23ee9051f0efe621a492be96
[11/20] powerpc/powernv: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/e5913db1ef22817e128f0a794752f7393205e00b
[12/20] powerpc/pseries: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/e14ff96d08f0ade9dd33081d909ad65a02a858c1
[13/20] powerpc/ps3: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/f1ba9b9474a9e32b9c173c91e71f713bfa7b2463
[14/20] powerpc/4xx: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/1e3d992d213928851f7ddec6f150fb54fe759b64
[15/20] powerpc/44x: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/1ee969be25ed21a1192ca569ad827013eb7fac04
[16/20] powerpc/embedded6xx: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/c0dc225ae7dd9f01d46ea779f7f169d49aa59b78
[17/20] powerpc/83xx: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/f4a88b0ef5c5f7ce218aced7d811a31dd311a0b0
[18/20] powerpc/85xx: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/407454cafd3f1878dae6bb839d8bac2db264300f
[19/20] powerpc/512x: Add __init attribute to eligible functions
https://git.kernel.org/powerpc/c/2493a24271dab3d5c1235a13cf6ee2d12773c9a1
[20/20] cuda/pmu: Make find_via_cuda/pmu init functions
https://git.kernel.org/powerpc/c/7da1d1ddd1f02e5de7497a0c849256912652fb6c
cheers
^ 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