[PATCH 24/32] powerpc/configs/64s: Drop REISERFS
No reason to use this anymore. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 4 1 file changed, 4 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index b7c6cd72a0ce..12d49f3e56b7 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -312,10 +312,6 @@ CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y -CONFIG_REISERFS_FS=m -CONFIG_REISERFS_FS_XATTR=y -CONFIG_REISERFS_FS_POSIX_ACL=y -CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y -- 2.39.2
[PATCH 23/32] powerpc/configs/64s: Use SHA512 for module signatures
Modern distros use SHA512 for module signing. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 4c347f6be401..b7c6cd72a0ce 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -77,6 +77,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_MODULE_SIG_SHA512=y CONFIG_PARTITION_ADVANCED=y CONFIG_BINFMT_MISC=m CONFIG_ZSWAP=y -- 2.39.2
[PATCH 16/32] powerpc/configs/64s: Enable YAMA, LANDLOCK & BPF LSMs
Multiple distros enable these. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 0aafe64cd1d7..8673277f9b20 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -6,6 +6,7 @@ CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT=y +CONFIG_BPF_LSM=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -357,8 +358,10 @@ CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_SECURITY=y +CONFIG_SECURITY_YAMA=y CONFIG_SECURITY_LOCKDOWN_LSM=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY_SIGNATURE=y CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y CONFIG_INTEGRITY_PLATFORM_KEYRING=y -- 2.39.2
[PATCH 21/32] powerpc/configs/64s: Enable SCHEDSTATS
Distros enable it. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 3154f307bba6..2cee399d3abc 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -407,6 +407,7 @@ CONFIG_DEBUG_VM=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y +CONFIG_SCHEDSTATS=y CONFIG_DEBUG_MUTEXES=y CONFIG_FUNCTION_TRACER=y CONFIG_LOCK_TORTURE_TEST=m -- 2.39.2
[PATCH 20/32] powerpc/configs/64s: Enable DEBUG_VM & other options
Fedora enables DEBUG_VM, which has led to occasions where a VM_BUG_ON() is not caught by upstream testing, but rather is first found in Fedora, which is not how it's meant to be. PAGE_OWNER & PAGE_POISONING both need to be enabled on the kernel command line, so should not add much overhead in normal operation. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index c8b49e33fd81..3154f307bba6 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -397,14 +397,20 @@ CONFIG_PRINTK_TIME=y CONFIG_PRINTK_CALLER=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_PAGE_OWNER=y +CONFIG_PAGE_POISONING=y CONFIG_DEBUG_RODATA_TEST=y +CONFIG_DEBUG_WX=y CONFIG_DEBUG_STACK_USAGE=y +CONFIG_DEBUG_VM=y +# CONFIG_DEBUG_VM_PGTABLE is not set CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_DEBUG_MUTEXES=y CONFIG_FUNCTION_TRACER=y CONFIG_LOCK_TORTURE_TEST=m +CONFIG_BUG_ON_DATA_CORRUPTION=y CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y -- 2.39.2
[PATCH 14/32] powerpc/configs/64s: Enable ZSWAP & ZRAM
Most distros enable these. In particular Fedore uses zram in the default install. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 07a92f02e1f8..59b9d8eb1c7b 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -78,6 +78,9 @@ CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_PARTITION_ADVANCED=y CONFIG_BINFMT_MISC=m +CONFIG_ZSWAP=y +CONFIG_Z3FOLD=y +CONFIG_ZSMALLOC=y # CONFIG_COMPAT_BRK is not set CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTREMOVE=y @@ -114,6 +117,7 @@ CONFIG_ELECTRA_CF=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_BLK_DEV_FD=y +CONFIG_ZRAM=m CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y -- 2.39.2
[PATCH 19/32] powerpc/configs/64s: Enable EMULATED_STATS
This is enabled in some of the other powerpc configs, and can be useful for debugging, so enable it in ppc64[le]_defconfig. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 8d4231fd878a..c8b49e33fd81 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -409,6 +409,7 @@ CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y CONFIG_BLK_DEV_IO_TRACE=y +CONFIG_PPC_EMULATED_STATS=y CONFIG_CODE_PATCHING_SELFTEST=y CONFIG_FTR_FIXUP_SELFTEST=y CONFIG_MSI_BITMAP_SELFTEST=y -- 2.39.2
[PATCH 18/32] powerpc/configs/64s: Enable KUNIT and most tests
All built as modules, so the tests only happen when the modules are loaded, not affecting normal boot time. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 43 1 file changed, 43 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 946307c54afa..8d4231fd878a 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -397,12 +397,14 @@ CONFIG_PRINTK_TIME=y CONFIG_PRINTK_CALLER=y CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_DEBUG_MUTEXES=y CONFIG_FUNCTION_TRACER=y +CONFIG_LOCK_TORTURE_TEST=m CONFIG_STACK_TRACER=y CONFIG_SCHED_TRACER=y CONFIG_FTRACE_SYSCALLS=y @@ -412,3 +414,44 @@ CONFIG_FTR_FIXUP_SELFTEST=y CONFIG_MSI_BITMAP_SELFTEST=y CONFIG_XMON=y CONFIG_BOOTX_TEXT=y +CONFIG_KUNIT=m +CONFIG_KUNIT_ALL_TESTS=m +CONFIG_LKDTM=m +CONFIG_TEST_MIN_HEAP=m +CONFIG_TEST_DIV64=m +CONFIG_BACKTRACE_SELF_TEST=m +CONFIG_TEST_REF_TRACKER=m +CONFIG_RBTREE_TEST=m +CONFIG_REED_SOLOMON_TEST=m +CONFIG_INTERVAL_TREE_TEST=m +CONFIG_PERCPU_TEST=m +CONFIG_ATOMIC64_SELFTEST=m +CONFIG_ASYNC_RAID6_TEST=m +CONFIG_TEST_HEXDUMP=m +CONFIG_STRING_SELFTEST=m +CONFIG_TEST_STRING_HELPERS=m +CONFIG_TEST_KSTRTOX=m +CONFIG_TEST_PRINTF=m +CONFIG_TEST_SCANF=m +CONFIG_TEST_BITMAP=m +CONFIG_TEST_UUID=m +CONFIG_TEST_XARRAY=m +CONFIG_TEST_MAPLE_TREE=m +CONFIG_TEST_RHASHTABLE=m +CONFIG_TEST_IDA=m +CONFIG_TEST_BITOPS=m +CONFIG_TEST_VMALLOC=m +CONFIG_TEST_USER_COPY=m +CONFIG_TEST_BPF=m +CONFIG_TEST_BLACKHOLE_DEV=m +CONFIG_FIND_BIT_BENCHMARK=m +CONFIG_TEST_FIRMWARE=m +CONFIG_TEST_SYSCTL=m +CONFIG_LINEAR_RANGES_TEST=m +CONFIG_TEST_UDELAY=m +CONFIG_TEST_STATIC_KEYS=m +CONFIG_TEST_KMOD=m +CONFIG_TEST_MEMCAT_P=m +CONFIG_TEST_MEMINIT=m +CONFIG_TEST_FREE_PAGES=m +CONFIG_MEMTEST=y -- 2.39.2
[PATCH 17/32] powerpc/configs/64s: Enable SELINUX
Fedora, CentOS, RHEL & SUSE all enable it. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 8673277f9b20..946307c54afa 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -358,6 +358,9 @@ CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_SECURITY=y +CONFIG_SECURITY_NETWORK=y +CONFIG_SECURITY_SELINUX=y +CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_YAMA=y CONFIG_SECURITY_LOCKDOWN_LSM=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y -- 2.39.2
[PATCH 15/32] powerpc/configs/64s: Enable SLAB hardening options
Fedora & CentOS enable these. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 59b9d8eb1c7b..0aafe64cd1d7 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -81,6 +81,10 @@ CONFIG_BINFMT_MISC=m CONFIG_ZSWAP=y CONFIG_Z3FOLD=y CONFIG_ZSMALLOC=y +# CONFIG_SLAB_MERGE_DEFAULT is not set +CONFIG_SLAB_FREELIST_RANDOM=y +CONFIG_SLAB_FREELIST_HARDENED=y +CONFIG_SHUFFLE_PAGE_ALLOCATOR=y # CONFIG_COMPAT_BRK is not set CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTREMOVE=y -- 2.39.2
[PATCH 13/32] powerpc/configs/64s: Enable CHECKPOINT_RESTORE
Most distros enable this. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index e853905c4e7e..07a92f02e1f8 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -32,6 +32,7 @@ CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y CONFIG_CGROUP_MISC=y CONFIG_USER_NS=y +CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y CONFIG_BLK_DEV_INITRD=y CONFIG_PROFILING=y -- 2.39.2
[PATCH 12/32] powerpc/configs/64s: Enable common CGROUP & related options
Distros enable these options. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 7e265cbbeaef..e853905c4e7e 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -19,15 +19,20 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=13 CONFIG_NUMA_BALANCING=y -CONFIG_CGROUPS=y CONFIG_MEMCG=y -CONFIG_CGROUP_SCHED=y +CONFIG_BLK_CGROUP=y +CONFIG_CFS_BANDWIDTH=y +CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_HUGETLB=y CONFIG_CPUSETS=y CONFIG_CGROUP_DEVICE=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y +CONFIG_CGROUP_MISC=y +CONFIG_USER_NS=y +CONFIG_SCHED_AUTOGROUP=y CONFIG_BLK_DEV_INITRD=y CONFIG_PROFILING=y CONFIG_PPC64=y -- 2.39.2
[PATCH 11/32] powerpc/configs/64s: Enable NO_HZ_FULL
At least Fedora & SUSE enable it. VIRT_CPU_ACCOUNTING_GEN is selected so no longer needs to be in the defconfig. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index ecad254eee6c..7e265cbbeaef 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -1,13 +1,12 @@ CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y -# CONFIG_CONTEXT_TRACKING_USER_FORCE is not set CONFIG_AUDIT=y +CONFIG_NO_HZ_FULL=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT=y CONFIG_PREEMPT_VOLUNTARY=y -CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y -- 2.39.2
[PATCH 10/32] powerpc/configs/64s: Enable common accounting options
These options are enabled by most distros. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 0e3b420aaa6e..ecad254eee6c 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -8,8 +8,13 @@ CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT=y CONFIG_PREEMPT_VOLUNTARY=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_PSI=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 -- 2.39.2
[PATCH 09/32] powerpc/configs/64s: Enable AUDIT
Essentially all distros enable it. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index b332b05a668f..0e3b420aaa6e 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -1,6 +1,7 @@ CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_CONTEXT_TRACKING_USER_FORCE is not set +CONFIG_AUDIT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BPF_SYSCALL=y -- 2.39.2
[PATCH 08/32] powerpc/configs/64s: Enable PREEMPT_VOLUNTARY
Traditionally on powerpc servers PREEMPT_NONE was used, but these days multiple distros are building with PREEMPT_VOLUNTARY - Ubuntu, Fedora & CentOS all enable it. So update the upstream config to reflect that, and get test coverage before code hits the distros. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index f185adc128db..b332b05a668f 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -5,6 +5,7 @@ CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_BPF_SYSCALL=y CONFIG_BPF_JIT=y +CONFIG_PREEMPT_VOLUNTARY=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y -- 2.39.2
[PATCH 07/32] powerpc/configs/64s: Select ARCH_WANT_DEFAULT_BPF_JIT
Tell the generic BPF code that the JIT should be enabled by default, rather than the interpreter. Most distros use CONFIG_BPF_JIT_ALWAYS_ON=y anyway, so this just updates upstream to more closely match that. Signed-off-by: Michael Ellerman --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 9fed732807fa..f8179e17325b 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -164,6 +164,7 @@ config PPC select ARCH_USE_CMPXCHG_LOCKREF if PPC64 select ARCH_USE_MEMTEST select ARCH_USE_QUEUED_RWLOCKS if PPC_QUEUED_SPINLOCKS + select ARCH_WANT_DEFAULT_BPF_JIT select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT select ARCH_WANT_IPC_PARSE_VERSION select ARCH_WANT_IRQS_OFF_ACTIVATE_MM -- 2.39.2
[PATCH 06/32] powerpc/configs/64s: Add secure boot options to defconfig
Add the numerous options required to get secure boot enabled. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index d98fe52a5892..f185adc128db 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -54,6 +54,7 @@ CONFIG_CRASH_DUMP=y CONFIG_FA_DUMP=y CONFIG_IRQ_ALL_CPUS=y CONFIG_SCHED_SMT=y +CONFIG_PPC_SECURE_BOOT=y CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=m @@ -335,13 +336,25 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y +CONFIG_SECURITY=y +CONFIG_SECURITY_LOCKDOWN_LSM=y +CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y +CONFIG_INTEGRITY_SIGNATURE=y +CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y +CONFIG_INTEGRITY_PLATFORM_KEYRING=y +CONFIG_IMA=y +CONFIG_IMA_KEXEC=y +CONFIG_IMA_DEFAULT_HASH_SHA256=y +CONFIG_IMA_WRITE_POLICY=y +CONFIG_IMA_APPRAISE=y +CONFIG_IMA_ARCH_POLICY=y +CONFIG_IMA_APPRAISE_MODSIG=y CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_WP512=m @@ -352,6 +365,8 @@ CONFIG_CRYPTO_SHA1_PPC=m CONFIG_CRYPTO_DEV_NX=y CONFIG_CRYPTO_DEV_NX_ENCRYPT=m CONFIG_CRYPTO_DEV_VMX=y +CONFIG_SYSTEM_TRUSTED_KEYRING=y +CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_PRINTK_TIME=y CONFIG_PRINTK_CALLER=y CONFIG_DEBUG_KERNEL=y -- 2.39.2
[PATCH 03/32] powerpc/configs/64s: Drop IPV6 which is default y
Since commit de551f2eb22a ("net: Build IPv6 into kernel by default"),
IPV6 is default y.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/ppc64_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 0a3a2fefb652..c4f3ce96d924 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -84,7 +84,6 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
-CONFIG_IPV6=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_ADVANCED is not set
CONFIG_BRIDGE=m
--
2.39.2
[PATCH 05/32] powerpc/configs/64s: Enable PAPR_SCM
This is a powerpc specific driver so add the symbols required to enable it so it gets some build/boot test coverage. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index 74477f89c108..d98fe52a5892 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -29,6 +29,7 @@ CONFIG_NR_CPUS=2048 CONFIG_DTL=y CONFIG_PPC_SMLPAR=y CONFIG_IBMEBUS=y +CONFIG_PAPR_SCM=m CONFIG_PPC_SVM=y CONFIG_PPC_MAPLE=y CONFIG_PPC_PASEMI=y @@ -69,6 +70,7 @@ CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTREMOVE=y CONFIG_KSM=y CONFIG_TRANSPARENT_HUGEPAGE=y +CONFIG_ZONE_DEVICE=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y -- 2.39.2
[PATCH 04/32] powerpc/configs/6s: Drop obsolete crypto ALGs
These algorithms were marked obsolete in commit 1674aea5f080 ("crypto:
Kconfig - mark unused ciphers as obsolete").
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/ppc64_defconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index c4f3ce96d924..74477f89c108 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -343,9 +343,6 @@ CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_WP512=m
-CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_KHAZAD=m
-CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_LZO=m
CONFIG_CRYPTO_CRC32C_VPMSUM=m
CONFIG_CRYPTO_MD5_PPC=m
--
2.39.2
[PATCH 01/32] powerpc/configs/64s: Update defconfig for symbol movement
Update ppc64_defconfig to account for symbols moving around, no actual changes. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/ppc64_defconfig | 42 ++-- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index d6949a6c5b2b..1028b90ce121 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -3,6 +3,8 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_CONTEXT_TRACKING_USER_FORCE is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_BPF_SYSCALL=y +CONFIG_BPF_JIT=y CONFIG_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y @@ -21,8 +23,6 @@ CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_BPF=y CONFIG_BLK_DEV_INITRD=y -CONFIG_BPF_SYSCALL=y -# CONFIG_COMPAT_BRK is not set CONFIG_PROFILING=y CONFIG_PPC64=y CONFIG_NR_CPUS=2048 @@ -54,15 +54,9 @@ CONFIG_CRASH_DUMP=y CONFIG_FA_DUMP=y CONFIG_IRQ_ALL_CPUS=y CONFIG_SCHED_SMT=y -CONFIG_HOTPLUG_PCI=y -CONFIG_HOTPLUG_PCI_RPA=m -CONFIG_HOTPLUG_PCI_RPA_DLPAR=m -CONFIG_PCCARD=y -CONFIG_ELECTRA_CF=y CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=m -CONFIG_VHOST_NET=m CONFIG_KPROBES=y CONFIG_JUMP_LABEL=y CONFIG_MODULES=y @@ -71,6 +65,7 @@ CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_PARTITION_ADVANCED=y CONFIG_BINFMT_MISC=m +# CONFIG_COMPAT_BRK is not set CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTREMOVE=y CONFIG_KSM=y @@ -98,7 +93,11 @@ CONFIG_NET_SCHED=y CONFIG_NET_CLS_BPF=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_BPF=m -CONFIG_BPF_JIT=y +CONFIG_HOTPLUG_PCI=y +CONFIG_HOTPLUG_PCI_RPA=m +CONFIG_HOTPLUG_PCI_RPA_DLPAR=m +CONFIG_PCCARD=y +CONFIG_ELECTRA_CF=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_BLK_DEV_FD=y @@ -267,9 +266,9 @@ CONFIG_LEDS_POWERNV=m CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m -CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_CXGB4=m CONFIG_MLX4_INFINIBAND=m +CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_SRP=m @@ -280,8 +279,9 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_DS1307=y CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m -CONFIG_LIBNVDIMM=y +CONFIG_VHOST_NET=m CONFIG_RAS=y +CONFIG_LIBNVDIMM=y CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y @@ -336,38 +336,38 @@ CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_CRYPTO_TEST=m +CONFIG_CRYPTO_BLOWFISH=m +CONFIG_CRYPTO_CAST6=m +CONFIG_CRYPTO_SERPENT=m +CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_HMAC=y -CONFIG_CRYPTO_CRC32C_VPMSUM=m -CONFIG_CRYPTO_MD5_PPC=m CONFIG_CRYPTO_MICHAEL_MIC=m -CONFIG_CRYPTO_SHA1_PPC=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_ANUBIS=m -CONFIG_CRYPTO_BLOWFISH=m -CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_KHAZAD=m -CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m -CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_LZO=m +CONFIG_CRYPTO_CRC32C_VPMSUM=m +CONFIG_CRYPTO_MD5_PPC=m +CONFIG_CRYPTO_SHA1_PPC=m CONFIG_CRYPTO_DEV_NX=y CONFIG_CRYPTO_DEV_NX_ENCRYPT=m CONFIG_CRYPTO_DEV_VMX=y CONFIG_PRINTK_TIME=y CONFIG_PRINTK_CALLER=y -CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y +CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_SOFTLOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_DEBUG_MUTEXES=y CONFIG_FUNCTION_TRACER=y -CONFIG_FTRACE_SYSCALLS=y -CONFIG_SCHED_TRACER=y CONFIG_STACK_TRACER=y +CONFIG_SCHED_TRACER=y +CONFIG_FTRACE_SYSCALLS=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_CODE_PATCHING_SELFTEST=y CONFIG_FTR_FIXUP_SELFTEST=y -- 2.39.2
[PATCH 02/32] powerpc/configs/64s: Drop SPLPAR which is default y
SPLPAR is default y since commit 20c0e8269e9d ("powerpc/pseries:
Implement paravirt qspinlocks for SPLPAR"), so doesn't need to be in the
defconfig.
Signed-off-by: Michael Ellerman
---
arch/powerpc/configs/ppc64_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 1028b90ce121..0a3a2fefb652 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -26,7 +26,6 @@ CONFIG_BLK_DEV_INITRD=y
CONFIG_PROFILING=y
CONFIG_PPC64=y
CONFIG_NR_CPUS=2048
-CONFIG_PPC_SPLPAR=y
CONFIG_DTL=y
CONFIG_PPC_SMLPAR=y
CONFIG_IBMEBUS=y
--
2.39.2
Re: [PATCH v2 2/2] Move Power10 feature, PPC_MODULE_FEATURE_P10.
Danny Tsen writes: > Move Power10 feature, PPC_MODULE_FEATURE_P10, definition to be in > arch/powerpc/include/asm/cpufeature.h. > > Signed-off-by: Danny Tsen > --- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > arch/powerpc/include/asm/cpufeature.h | 1 + > 2 files changed, 1 insertion(+), 1 deletion(-) Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c > b/arch/powerpc/crypto/aes-gcm-p10-glue.c > index 1533c8cdd26f..bd3475f5348d 100644 > --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c > +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c > @@ -22,7 +22,6 @@ > #include > #include > > -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) > #define PPC_ALIGN 16 > #define GCM_IV_SIZE 12 > > diff --git a/arch/powerpc/include/asm/cpufeature.h > b/arch/powerpc/include/asm/cpufeature.h > index f6f790a90367..2dcc66225e7f 100644 > --- a/arch/powerpc/include/asm/cpufeature.h > +++ b/arch/powerpc/include/asm/cpufeature.h > @@ -22,6 +22,7 @@ > */ > > #define PPC_MODULE_FEATURE_VEC_CRYPTO(32 + > ilog2(PPC_FEATURE2_VEC_CRYPTO)) > +#define PPC_MODULE_FEATURE_P10 (32 + > ilog2(PPC_FEATURE2_ARCH_3_1)) > > #define cpu_feature(x) (x) > > -- > 2.31.1
Re: [PATCH v2 1/2] Remove POWER10_CPU dependency.
Danny Tsen writes: > Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. ... using the existing call to module_cpu_feature_match() :) > Signed-off-by: Danny Tsen > --- > arch/powerpc/crypto/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig > index 1f8f02b494e1..7113f9355165 100644 > --- a/arch/powerpc/crypto/Kconfig > +++ b/arch/powerpc/crypto/Kconfig > @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE > > config CRYPTO_AES_GCM_P10 > tristate "Stitched AES/GCM acceleration support on P10 or later CPU > (PPC)" > - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN > + depends on PPC64 && CPU_LITTLE_ENDIAN > select CRYPTO_LIB_AES > select CRYPTO_ALGAPI > select CRYPTO_AEAD > -- > 2.31.1
Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Laurent Dufour writes:
> On 13/04/2023 15:37:59, Michael Ellerman wrote:
>> Laurent Dufour writes:
>>> There is no SMT level recorded in the kernel neither in user space.
>>> Indeed there is no real constraint about that and mixed SMT levels are
>>> allowed and system is working fine this way.
>>>
>>> However when new CPU are added, the kernel is onlining all the threads
>>> which is leading to mixed SMT levels and confuse end user a bit.
>>>
>>> To prevent this exports a SMT level from the kernel so user space
>>> application like the energy daemon, could read it to adjust their settings.
>>> There is no action unless recording the value when a SMT value is written
>>> into the new sysfs entry. User space applications like ppc64_cpu should
>>> update the sysfs when changing the SMT level to keep the system consistent.
>>>
>>> Suggested-by: Srikar Dronamraju
>>> Signed-off-by: Laurent Dufour
>>> ---
>>> arch/powerpc/platforms/pseries/pseries.h | 3 ++
>>> arch/powerpc/platforms/pseries/smp.c | 39
>>> 2 files changed, 42 insertions(+)
>>
>> There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
>>
>> I think we should be enabling that on powerpc and then adapting it to
>> our needs, rather than adding a pseries specific file.
>
> Thanks Michael, I was not aware of this sysfs interface.
>
>> Currently the generic code is only aware of SMT on/off, so it would need
>> to be taught about SMT4 and 8 at least.
>
> Do you think we should limit our support to SMT4 and SMT8 only?
Possibly? Currently the SMT state is represented by an enum:
enum cpuhp_smt_control {
CPU_SMT_ENABLED,
CPU_SMT_DISABLED,
CPU_SMT_FORCE_DISABLED,
CPU_SMT_NOT_SUPPORTED,
CPU_SMT_NOT_IMPLEMENTED,
};
Adding two states for SMT4 and SMT8 seeems like it might be acceptable.
On the other hand if we want to support artbitrary SMT values from 3 to
8 then it might be better to store that value separately from the state
enum.
TBH I'm not sure whether we want to support values other than 1/2/4/8
via this interface.
A user who wants some odd numbered SMT value can always configure that
manually using the existing tools.
But maybe it's less confusing if this interface supports all values?
Even if they're unlikely to get much usage.
>> There are already hooks in the generic code to check the SMT level when
>> bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
>> hotplug case too, though maybe we need some additional logic.
>>
>> Wiring up the basic support is pretty straight forward, something like
>> the diff below.
>
> I'll look into how to wire this up.
> Thanks a lot!
Thanks.
cheers
Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms
Li Yang writes: > On Tue, Feb 21, 2023 at 1:52 PM Paul Gortmaker > wrote: >> >> [This RFC is proposed for v6.4 and hence is based off linux-next.] >> >> In a similar theme to the e300/MPC83xx evaluation platform removal[1], >> this targets removal of some 13 --> 21 year old e500/MPC85xx evaluation >> boards that were produced in limited numbers and primarily made available >> to hardware/software developers to shape their own boards and BSPs. > > These e500 platforms are similar to the e300 platforms that they are > still being shipped, the targeting market probably caused it to have a > longer life cycle. > ... > > The difference here from the e300 platforms is that MPC8540ADS, > MPC8560ADS, MPC8548CDS, MPC8568-MDS are the only reference platforms > supplied by us for these SoCs. We don't have a separation of > evaluation platforms vs product-like platforms like we did later. > That probably means even if they don't look like "hobbyist" friendly > they are more likely to be still in use. OK. But what is the chance anyone is booting upstream kernels on them? I assume no one at NXP is testing upstream on those boards? cheers
Re: [PATCH 1/2] start_kernel: add no_stack_protector fn attr
ndesaulni...@google.com writes:
> Back during the discussion of
> commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
> we discussed the need for a function attribute to control the omission
> of stack protectors on a per-function basis; at the time Clang had
> support for no_stack_protector but GCC did not. This was fixed in
> gcc-11. Now that the function attribute is available, let's start using
> it.
>
> Callers of boot_init_stack_canary need to use this function attribute
> unless they're compiled with -fno-stack-protector, otherwise the canary
> stored in the stack slot of the caller will differ upon the call to
> boot_init_stack_canary. This will lead to a call to __stack_chk_fail
> then panic.
>
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722
> Link:
> https://lore.kernel.org/all/20200316130414.gc12...@hirez.programming.kicks-ass.net/
> Signed-off-by: Nick Desaulniers
> ---
> arch/powerpc/kernel/smp.c | 1 +
> include/linux/compiler_attributes.h | 12
> init/main.c | 3 ++-
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 6b90f10a6c81..7d4c12b1abb7 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -1603,6 +1603,7 @@ static void add_cpu_to_masks(int cpu)
> }
>
> /* Activate a secondary processor. */
> +__no_stack_protector
> void start_secondary(void *unused)
> {
> unsigned int cpu = raw_smp_processor_id();
start_secondary() doesn't return, so it won't actually crash, but it
obviously makes sense for it to be marked with __no_stack_protector.
There's quite a few other places we could add __no_stack_protector
annotations in powerpc code, and then make the changes to CFLAGS to
disable stack protector conditional on GCC < 11.
So I guess this patch is fine, but there's more that could be done.
Acked-by: Michael Ellerman (powerpc)
cheers
Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Hi Laurent,
Laurent Dufour writes:
> There is no SMT level recorded in the kernel neither in user space.
> Indeed there is no real constraint about that and mixed SMT levels are
> allowed and system is working fine this way.
>
> However when new CPU are added, the kernel is onlining all the threads
> which is leading to mixed SMT levels and confuse end user a bit.
>
> To prevent this exports a SMT level from the kernel so user space
> application like the energy daemon, could read it to adjust their settings.
> There is no action unless recording the value when a SMT value is written
> into the new sysfs entry. User space applications like ppc64_cpu should
> update the sysfs when changing the SMT level to keep the system consistent.
>
> Suggested-by: Srikar Dronamraju
> Signed-off-by: Laurent Dufour
> ---
> arch/powerpc/platforms/pseries/pseries.h | 3 ++
> arch/powerpc/platforms/pseries/smp.c | 39
> 2 files changed, 42 insertions(+)
There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
I think we should be enabling that on powerpc and then adapting it to
our needs, rather than adding a pseries specific file.
Currently the generic code is only aware of SMT on/off, so it would need
to be taught about SMT4 and 8 at least.
There are already hooks in the generic code to check the SMT level when
bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
hotplug case too, though maybe we need some additional logic.
Wiring up the basic support is pretty straight forward, something like
the diff below.
cheers
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 0f123f1f62a1..a48576f1c579 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -260,6 +260,7 @@ config PPC
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_VIRT_CPU_ACCOUNTING
select HAVE_VIRT_CPU_ACCOUNTING_GEN
+ select HOTPLUG_SMT if HOTPLUG_CPU
select HUGETLB_PAGE_SIZE_VARIABLE if PPC_BOOK3S_64 && HUGETLB_PAGE
select IOMMU_HELPER if PPC64
select IRQ_DOMAIN
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 8a4d4f4d9749..bd23ba716d23 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -143,5 +143,8 @@ static inline int cpu_to_coregroup_id(int cpu)
#endif
#endif
+bool topology_is_primary_thread(unsigned int cpu);
+bool topology_smt_supported(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_TOPOLOGY_H */
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 265801a3e94c..8619609809d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1769,4 +1769,20 @@ void __noreturn arch_cpu_idle_dead(void)
start_secondary_resume();
}
+/**
+ * topology_is_primary_thread - Check whether CPU is the primary SMT thread
+ * @cpu: CPU to check
+ */
+bool topology_is_primary_thread(unsigned int cpu)
+{
+ return cpu == cpu_first_thread_sibling(cpu);
+}
+
+/**
+ * topology_smt_supported - Check whether SMT is supported by the CPUs
+ */
+bool topology_smt_supported(void)
+{
+ return threads_per_core > 1;
+}
#endif
Re: [PATCH] Remove POWER10_CPU dependency and move PPC_MODULE_FEATURE_P10.
Danny Tsen writes: > Remove Power10 dependency in Kconfig and detect Power10 feature at runtime. > Move PPC_MODULE_FEATURE_P10 definition to be in > arch/powerpc/include/asm/cpufeature.h. This should be two patches, one for the Kconfig change and one moving the feature flag. Also don't you need a cpu feature check in p10_init()? Otherwise the driver can be loaded on non-P10 CPUs, either by being built-in, or manually. cheers > Signed-off-by: Danny Tsen > --- > arch/powerpc/crypto/Kconfig| 2 +- > arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 - > arch/powerpc/include/asm/cpufeature.h | 1 + > 3 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig > index 1f8f02b494e1..7113f9355165 100644 > --- a/arch/powerpc/crypto/Kconfig > +++ b/arch/powerpc/crypto/Kconfig > @@ -96,7 +96,7 @@ config CRYPTO_AES_PPC_SPE > > config CRYPTO_AES_GCM_P10 > tristate "Stitched AES/GCM acceleration support on P10 or later CPU > (PPC)" > - depends on PPC64 && POWER10_CPU && CPU_LITTLE_ENDIAN > + depends on PPC64 && CPU_LITTLE_ENDIAN > select CRYPTO_LIB_AES > select CRYPTO_ALGAPI > select CRYPTO_AEAD > diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c > b/arch/powerpc/crypto/aes-gcm-p10-glue.c > index 1533c8cdd26f..bd3475f5348d 100644 > --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c > +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c > @@ -22,7 +22,6 @@ > #include > #include > > -#define PPC_MODULE_FEATURE_P10 (32 + ilog2(PPC_FEATURE2_ARCH_3_1)) > #define PPC_ALIGN 16 > #define GCM_IV_SIZE 12 > > diff --git a/arch/powerpc/include/asm/cpufeature.h > b/arch/powerpc/include/asm/cpufeature.h > index f6f790a90367..2dcc66225e7f 100644 > --- a/arch/powerpc/include/asm/cpufeature.h > +++ b/arch/powerpc/include/asm/cpufeature.h > @@ -22,6 +22,7 @@ > */ > > #define PPC_MODULE_FEATURE_VEC_CRYPTO(32 + > ilog2(PPC_FEATURE2_VEC_CRYPTO)) > +#define PPC_MODULE_FEATURE_P10 (32 + > ilog2(PPC_FEATURE2_ARCH_3_1)) > > #define cpu_feature(x) (x) > > -- > 2.31.1
Re: [PATCH] powerpc/mpc52xx_lpbfifo: Drop unused functions
Uwe Kleine-König writes: > On Wed, Dec 28, 2022 at 03:51:29PM +0100, Uwe Kleine-König wrote: >> The four exported functions mpc52xx_lpbfifo_submit(), >> mpc52xx_lpbfifo_abort(), mpc52xx_lpbfifo_poll(), and >> mpc52xx_lpbfifo_start_xfer() are not used. So they can be dropped and the >> definitions needed to call them can be moved into the driver file. >> >> Signed-off-by: Uwe Kleine-König > > I never got feedback about this driver and it has not appeared in next > up to now. Did it fell through the cracks? Yeah. I was hoping someone would explain what's going on with the driver. Presumably there are some out-of-tree drivers that use the routines provided by this driver? I think rather than merging this patch, which keeps the code but makes it completely useless, do you mind sending a patch to remove the whole driver? Maybe that will get someone's attention. cheers
Re: [PATCH] powerpc/64: Always build with 128-bit long double
Hamza Mahfooz writes:
> On 4/4/23 06:28, Michael Ellerman wrote:
>> The amdgpu driver builds some of its code with hard-float enabled,
>> whereas the rest of the kernel is built with soft-float.
>>
>> When building with 64-bit long double, if soft-float and hard-float
>> objects are linked together, the build fails due to incompatible ABI
>> tags.
>>
>> In the past there have been build errors in the amdgpu driver caused by
>> this, some of those were due to bad intermingling of soft & hard-float
>> code, but those issues have now all been fixed since commit c92b7fe0d92a
>> ("drm/amd/display: move remaining FPU code to dml folder").
>>
>> However it's still possible for soft & hard-float objects to end up
>> linked together, if the amdgpu driver is built-in to the kernel along
>> with the test_emulate_step.c code, which uses soft-float. That happens
>> in an allyesconfig build.
>>
>> Currently those build errors are avoided because the amdgpu driver is
>> gated on 128-bit long double being enabled. But that's not a detail the
>> amdgpu driver should need to be aware of, and if another driver starts
>> using hard-float the same problem would occur.
>>
>> All versions of the 64-bit ABI specify that long-double is 128-bits.
>> However some compilers, notably the kernel.org ones, are built to use
>> 64-bit long double by default.
>>
>> Apart from this issue of soft vs hard-float, the kernel doesn't care
>> what size long double is. In particular the kernel using 128-bit long
>> double doesn't impact userspace's ability to use 64-bit long double, as
>> musl does.
>>
>> So always build the 64-bit kernel with 128-bit long double. That should
>> avoid any build errors due to the incompatible ABI tags. Excluding the
>> code that uses soft/hard-float, the vmlinux is identical with/without
>> the flag.
>>
>> It does mean any code which is incorrectly intermingling soft &
>> hard-float code will build without error, so those bugs will need to be
>> caught by testing rather than at build time.
>>
>> For more background see:
>>- commit d11219ad53dc ("amdgpu: disable powerpc support for the newer
>> display engine")
>>- commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
>>-
>> https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397...@app.fastmail.com
>>
>> Signed-off-by: Michael Ellerman
>
> Reviewed-by: Hamza Mahfooz
Thanks.
> If you'd prefer to have this go through the amdgpu branch, please let
> me know.
I think it makes more sense to go via the powerpc tree, it will get more
testing on powerpc that way.
cheers
Re: [PATCH] selftests/powerpc: Replace obsolete memalign() with posix_memalign()
Deming Wang writes:
> memalign() is obsolete according to its manpage.
>
> Replace memalign() with posix_memalign() and remove malloc.h include
> that was there for memalign().
>
> As a pointer is passed into posix_memalign(), initialize *s to NULL
> to silence a warning about the function's return value being used as
> uninitialized (which is not valid anyway because the error is properly
> checked before p is returned).
The patch doesn't do that. There is no p?
I think you've copied the change log for a whole bunch of commits but
not updated them to be accurate for each change?
cheers
> diff --git a/tools/testing/selftests/powerpc/stringloops/strlen.c
> b/tools/testing/selftests/powerpc/stringloops/strlen.c
> index 9055ebc484d0..f9c1f9cc2d32 100644
> --- a/tools/testing/selftests/powerpc/stringloops/strlen.c
> +++ b/tools/testing/selftests/powerpc/stringloops/strlen.c
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include
> #include
> #include
> #include
> @@ -51,10 +50,11 @@ static void bench_test(char *s)
> static int testcase(void)
> {
> char *s;
> + int ret;
> unsigned long i;
>
> - s = memalign(128, SIZE);
> - if (!s) {
> + ret = posix_memalign((void **), 128, SIZE);
> + if (ret < 0) {
> perror("memalign");
> exit(1);
> }
> --
> 2.27.0
Re: [PATCH v2 15/19] arch/powerpc: Implement with generic helpers
Thomas Zimmermann writes:
> Replace the architecture's fb_is_primary_device() with the generic
> one from . No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> ---
> arch/powerpc/include/asm/fb.h | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
Looks fine.
Acked-by: Michael Ellerman (powerpc)
cheers
> diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
> index 6541ab77c5b9..5f1a2e5f7654 100644
> --- a/arch/powerpc/include/asm/fb.h
> +++ b/arch/powerpc/include/asm/fb.h
> @@ -2,8 +2,8 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> #include
> +
> #include
>
> static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> @@ -13,10 +13,8 @@ static inline void fb_pgprotect(struct file *file, struct
> vm_area_struct *vma,
>vma->vm_end - vma->vm_start,
>vma->vm_page_prot);
> }
> +#define fb_pgprotect fb_pgprotect
>
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
> --
> 2.40.0
Re: linux-next: manual merge of the drm tree with the powerpc tree
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/Kconfig
>
> between commit:
>
> 78f0929884d4 ("powerpc/64: Always build with 128-bit long double")
>
> from the powerpc tree and commit:
>
> 4652ae7a51b7 ("drm/amd/display: Rename DCN config to FP")
>
> from the drm tree.
> I fixed it up (I used the powerpc version - with "(PPC64 && ALTIVEC)")
> and can carry the fix as necessary.
Thanks, that's the right resolution.
Not much we can do to avoid that conflict, we'll just have to tell Linus
about it at pull request time.
cheers
Re: [PATCH] powerpc/boot: Fix crt0.S current address branch form
Michael Ellerman writes: > Nicholas Piggin writes: >> Use the preferred form of branch-and-link for finding the current >> address so objtool doesn't think it is an unannotated intra-function >> call. > > We don't run objtool on this code in mainline AFAIK. Because BOOTAS > doesn't call it. But as Nick pointed out, if you run: $ make arch/powerpc/boot/crt0.o It does run objtool, because it uses the generic cmd_as_o_S rule instead of the BOOTAS rule. cheers
[PATCH] powerpc/corenet: Add PPC_QEMU_E500 to corenet configs
Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate corenet64_smp_defconfig and corenet32_smp_defconfig. That then allows both those configs to build kernels that boot in qemu using the ppce500 machine type and respectively -cpu e5500 or -cpu e500mc. The code that is added by PPC_QEMU_E500 just defines another machine with a probe function that recognises qemu, so there should be no change when booting on actual hardware supported by CORENET_GENERIC. The increase in vmlinux size is less than 1KB. Signed-off-by: Michael Ellerman --- arch/powerpc/configs/corenet_base.config | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/corenet_base.config b/arch/powerpc/configs/corenet_base.config index b568d465e59e..1c40de1e764b 100644 --- a/arch/powerpc/configs/corenet_base.config +++ b/arch/powerpc/configs/corenet_base.config @@ -1 +1,2 @@ CONFIG_CORENET_GENERIC=y +CONFIG_PPC_QEMU_E500=y -- 2.39.2
Re: [PATCH] KVM: PPC: BOOK3S: book3s_hv_nested.c: improve branch prediction for k.alloc
Kautuk Consul writes: > On 2023-04-07 09:01:29, Sean Christopherson wrote: >> On Fri, Apr 07, 2023, Bagas Sanjaya wrote: >> > On Fri, Apr 07, 2023 at 05:31:47AM -0400, Kautuk Consul wrote: >> > > I used the unlikely() macro on the return values of the k.alloc >> > > calls and found that it changes the code generation a bit. >> > > Optimize all return paths of k.alloc calls by improving >> > > branch prediction on return value of k.alloc. >> >> Nit, this is improving code generation, not branch prediction. > Sorry my mistake. >> >> > What about below? >> > >> > "Improve branch prediction on kmalloc() and kzalloc() call by using >> > unlikely() macro to optimize their return paths." >> >> Another nit, using unlikely() doesn't necessarily provide a measurable >> optimization. >> As above, it does often improve code generation for the happy path, but that >> doesn't >> always equate to improved performance, e.g. if the CPU can easily predict >> the branch >> and/or there is no impact on the cache footprint. > I see. I will submit a v2 of the patch with a better and more accurate > description. Does anyone else have any comments before I do so ? In general I think unlikely should be saved for cases where either the compiler is generating terrible code, or the likelyness of the condition might be surprising to a human reader. eg. if you had some code that does a NULL check and it's *expected* that the value is NULL, then wrapping that check in likely() actually adds information for a human reader. Also please don't use unlikely in init paths or other cold paths, it clutters the code (only slightly but a little) and that's not worth the possible tiny benefit for code that only runs once or infrequently. I would expect the compilers to do the right thing in all these cases without the unlikely. But if you can demonstrate that they meaningfully improve the code generation with a before/after dissassembly then I'd be interested. cheers
Re: [PATCH] powerpc/boot: Fix crt0.S current address branch form
Nicholas Piggin writes: > Use the preferred form of branch-and-link for finding the current > address so objtool doesn't think it is an unannotated intra-function > call. We don't run objtool on this code in mainline AFAIK. Because BOOTAS doesn't call it. Did you actually see a warning, or are you just anticipating that it would warn about it? This diff would run it on boot asm and seems to build OK, so maybe we should do that. diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 08071bac056d..5d3a4c5354d7 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -223,7 +223,7 @@ quiet_cmd_bootcc = BOOTCC $@ cmd_bootcc = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTCFLAGS) -c -o $@ $< quiet_cmd_bootas = BOOTAS $@ - cmd_bootas = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $< + cmd_bootas = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $< $(cmd_objtool) quiet_cmd_bootar = BOOTAR $@ cmd_bootar = $(BOOTAR) $(BOOTARFLAGS) $@. $(real-prereqs); mv $@. $@ cheers
[PATCH 1/4] powerpc/64: Mark prep_irq_for_idle() __cpuidle
Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").
Mark prep_irq_for_idle() __cpuidle, which is equivalent to noinstr, to
enforce that.
Suggested-by: Peter Zijlstra
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/irq_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq_64.c b/arch/powerpc/kernel/irq_64.c
index c788c55512ed..2ab0e8d84c1d 100644
--- a/arch/powerpc/kernel/irq_64.c
+++ b/arch/powerpc/kernel/irq_64.c
@@ -354,7 +354,7 @@ EXPORT_SYMBOL(arch_local_irq_restore);
* disabled and marked as such, so the local_irq_enable() call
* in arch_cpu_idle() will properly re-enable everything.
*/
-bool prep_irq_for_idle(void)
+__cpuidle bool prep_irq_for_idle(void)
{
/*
* First we need to hard disable to ensure no interrupt
--
2.39.2
[PATCH 2/4] powerpc/64: Don't call trace_hardirqs_on() in prep_irq_for_idle()
Since commit a01353cf1896 ("cpuidle: Fix ct_idle_*() usage"), the
cpuidle entry code calls trace_hardirqs_on() (actually
trace_hardirqs_on_prepare()) in ct_cpuidle_enter() before calling into
the cpuidle driver.
Suggested-by: Peter Zijlstra
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/irq_64.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/irq_64.c b/arch/powerpc/kernel/irq_64.c
index 2ab0e8d84c1d..938e66829eae 100644
--- a/arch/powerpc/kernel/irq_64.c
+++ b/arch/powerpc/kernel/irq_64.c
@@ -348,9 +348,8 @@ EXPORT_SYMBOL(arch_local_irq_restore);
* already the case when ppc_md.power_save is called). The function
* will return whether to enter power save or just return.
*
- * In the former case, it will have notified lockdep of interrupts
- * being re-enabled and generally sanitized the lazy irq state,
- * and in the latter case it will leave with interrupts hard
+ * In the former case, it will have generally sanitized the lazy irq
+ * state, and in the latter case it will leave with interrupts hard
* disabled and marked as such, so the local_irq_enable() call
* in arch_cpu_idle() will properly re-enable everything.
*/
@@ -370,9 +369,6 @@ __cpuidle bool prep_irq_for_idle(void)
if (lazy_irq_pending())
return false;
- /* Tell lockdep we are about to re-enable */
- trace_hardirqs_on();
-
/*
* Mark interrupts as soft-enabled and clear the
* PACA_IRQ_HARD_DIS from the pending mask since we
--
2.39.2
[PATCH 4/4] powerpc/pseries: Always inline functions called from cpuidle
Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").
Force inlining of the inline functions called from cpuidle, to ensure
they are not emitted out-of-line and then available for tracing.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/idle.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/idle.h b/arch/powerpc/include/asm/idle.h
index accd1f50085a..00f360667391 100644
--- a/arch/powerpc/include/asm/idle.h
+++ b/arch/powerpc/include/asm/idle.h
@@ -9,17 +9,17 @@ DECLARE_PER_CPU(u64, idle_spurr_cycles);
DECLARE_PER_CPU(u64, idle_entry_purr_snap);
DECLARE_PER_CPU(u64, idle_entry_spurr_snap);
-static inline void snapshot_purr_idle_entry(void)
+static __always_inline void snapshot_purr_idle_entry(void)
{
*this_cpu_ptr(_entry_purr_snap) = mfspr(SPRN_PURR);
}
-static inline void snapshot_spurr_idle_entry(void)
+static __always_inline void snapshot_spurr_idle_entry(void)
{
*this_cpu_ptr(_entry_spurr_snap) = mfspr(SPRN_SPURR);
}
-static inline void update_idle_purr_accounting(void)
+static __always_inline void update_idle_purr_accounting(void)
{
u64 wait_cycles;
u64 in_purr = *this_cpu_ptr(_entry_purr_snap);
@@ -29,7 +29,7 @@ static inline void update_idle_purr_accounting(void)
get_lppaca()->wait_state_cycles = cpu_to_be64(wait_cycles);
}
-static inline void update_idle_spurr_accounting(void)
+static __always_inline void update_idle_spurr_accounting(void)
{
u64 *idle_spurr_cycles_ptr = this_cpu_ptr(_spurr_cycles);
u64 in_spurr = *this_cpu_ptr(_entry_spurr_snap);
@@ -37,7 +37,7 @@ static inline void update_idle_spurr_accounting(void)
*idle_spurr_cycles_ptr += mfspr(SPRN_SPURR) - in_spurr;
}
-static inline void pseries_idle_prolog(void)
+static __always_inline void pseries_idle_prolog(void)
{
ppc64_runlatch_off();
snapshot_purr_idle_entry();
@@ -49,7 +49,7 @@ static inline void pseries_idle_prolog(void)
get_lppaca()->idle = 1;
}
-static inline void pseries_idle_epilog(void)
+static __always_inline void pseries_idle_epilog(void)
{
update_idle_purr_accounting();
update_idle_spurr_accounting();
--
2.39.2
[PATCH 3/4] cpuidle: pseries: Mark ->enter() functions as __cpuidle
Code in the idle path is not allowed to be instrumented because RCU is
disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
noinstr/__cpuidle usage").
Mark the cpuidle ->enter() callbacks as __cpuidle and use the
raw_local_irq_*() routines to ensure that is the case.
Reported-by: Sachin Sant
Suggested-by: Peter Zijlstra
Signed-off-by: Michael Ellerman
---
drivers/cpuidle/cpuidle-pseries.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-pseries.c
b/drivers/cpuidle/cpuidle-pseries.c
index 1bad4d2b7be3..a7d33f3ee01e 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -33,16 +33,16 @@ static struct cpuidle_state *cpuidle_state_table
__read_mostly;
static u64 snooze_timeout __read_mostly;
static bool snooze_timeout_en __read_mostly;
-static int snooze_loop(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+static __cpuidle
+int snooze_loop(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+ int index)
{
u64 snooze_exit_time;
set_thread_flag(TIF_POLLING_NRFLAG);
pseries_idle_prolog();
- local_irq_enable();
+ raw_local_irq_enable();
snooze_exit_time = get_tb() + snooze_timeout;
dev->poll_time_limit = false;
@@ -65,14 +65,14 @@ static int snooze_loop(struct cpuidle_device *dev,
HMT_medium();
clear_thread_flag(TIF_POLLING_NRFLAG);
- local_irq_disable();
+ raw_local_irq_disable();
pseries_idle_epilog();
return index;
}
-static void check_and_cede_processor(void)
+static __cpuidle void check_and_cede_processor(void)
{
/*
* Ensure our interrupt state is properly tracked,
@@ -216,9 +216,9 @@ static int __init parse_cede_parameters(void)
#define NR_DEDICATED_STATES2 /* snooze, CEDE */
static u8 cede_latency_hint[NR_DEDICATED_STATES];
-static int dedicated_cede_loop(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+static __cpuidle
+int dedicated_cede_loop(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+ int index)
{
u8 old_latency_hint;
@@ -230,7 +230,7 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
HMT_medium();
check_and_cede_processor();
- local_irq_disable();
+ raw_local_irq_disable();
get_lppaca()->donate_dedicated_cpu = 0;
get_lppaca()->cede_latency_hint = old_latency_hint;
@@ -239,9 +239,9 @@ static int dedicated_cede_loop(struct cpuidle_device *dev,
return index;
}
-static int shared_cede_loop(struct cpuidle_device *dev,
- struct cpuidle_driver *drv,
- int index)
+static __cpuidle
+int shared_cede_loop(struct cpuidle_device *dev, struct cpuidle_driver *drv,
+int index)
{
pseries_idle_prolog();
@@ -255,7 +255,7 @@ static int shared_cede_loop(struct cpuidle_device *dev,
*/
check_and_cede_processor();
- local_irq_disable();
+ raw_local_irq_disable();
pseries_idle_epilog();
return index;
--
2.39.2
[PATCH] powerpc/irq: Mark check_return_regs_valid() notrace
check_return_regs_valid() is called from the middle of the irq exit
handling, which is all notrace, so mark it notrace also.
Rerported-by: Sachin Sant
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/interrupt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index 0ec1581619db..e34c72285b4e 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -95,7 +95,7 @@ static notrace void booke_load_dbcr0(void)
#endif
}
-static void check_return_regs_valid(struct pt_regs *regs)
+static notrace void check_return_regs_valid(struct pt_regs *regs)
{
#ifdef CONFIG_PPC_BOOK3S_64
unsigned long trap, srr0, srr1;
--
2.39.2
Re: [PATCH] powerpc: Use of_address_to_resource()
Michael Ellerman writes: > On Sun, 19 Mar 2023 11:31:53 -0500, Rob Herring wrote: >> Replace open coded reading of "reg" or of_get_address()/ >> of_translate_address() calls with a single call to >> of_address_to_resource(). >> >> > > Applied to powerpc/next. > > [1/1] powerpc: Use of_address_to_resource() > > https://git.kernel.org/powerpc/c/2500763dd3db37fad94d9b506907c59c2f5e97c6 I actually merged v3, b4 got confused when sending the thanks. cheers
Re: [PATCH] macintosh/windfarm_smu_sat: Add missing of_node_put()
On Thu, 30 Mar 2023 11:35:58 +0800, Liang He wrote: > We call of_node_get() in wf_sat_probe() after sat is created, > so we need the of_node_put() before *kfree(sat)*. > > Applied to powerpc/next. [1/1] macintosh/windfarm_smu_sat: Add missing of_node_put() https://git.kernel.org/powerpc/c/631cf002826007ab7415258ee647dcaf8845ad5a cheers
Re: [PATCH v3] powerpc: Use of_address_to_resource()
On Wed, 29 Mar 2023 17:03:36 -0500, Rob Herring wrote: > Replace open coded reading of "reg" or of_get_address()/ > of_translate_address() calls with a single call to > of_address_to_resource(). > > Applied to powerpc/next. [1/1] powerpc: Use of_address_to_resource() https://git.kernel.org/powerpc/c/2500763dd3db37fad94d9b506907c59c2f5e97c6 cheers
Re: [PATCH] powerpc: xics: Use of_address_count()
On Mon, 27 Mar 2023 17:30:56 -0500, Rob Herring wrote: > icp_native_init_one_node() only needs the number of entries in "reg". > Replace the open coded "reg" parsing with of_address_count() to get the > number of "reg" entries. > > Applied to powerpc/next. [1/1] powerpc: xics: Use of_address_count() https://git.kernel.org/powerpc/c/037c47a436eab2d336d5e131ab1c1394f223a57b cheers
Re: [PATCH] powerpc: Use of_property_read_bool() for boolean properties
On Fri, 10 Mar 2023 08:46:57 -0600, Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. > Convert reading boolean properties to to of_property_read_bool(). > > Applied to powerpc/next. [1/1] powerpc: Use of_property_read_bool() for boolean properties https://git.kernel.org/powerpc/c/4d57e3515e3838b12eccbeb5e0e52f053e3f638a cheers
Re: [PATCH] powerpc: Use of_property_present() for testing DT property presence
On Fri, 10 Mar 2023 08:46:56 -0600, Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. As > part of this, convert of_get_property/of_find_property calls to the > recently added of_property_present() helper when we just want to test > for presence of a property and nothing more. > > [...] Applied to powerpc/next. [1/1] powerpc: Use of_property_present() for testing DT property presence https://git.kernel.org/powerpc/c/857d423c74228cfa064f79ff3a16b163fdb8d542 cheers
Re: [PATCH] powerpc: Use of_address_to_resource()
On Sun, 19 Mar 2023 11:31:53 -0500, Rob Herring wrote: > Replace open coded reading of "reg" or of_get_address()/ > of_translate_address() calls with a single call to > of_address_to_resource(). > > Applied to powerpc/next. [1/1] powerpc: Use of_address_to_resource() https://git.kernel.org/powerpc/c/2500763dd3db37fad94d9b506907c59c2f5e97c6 cheers
Re: [PATCH] powerpc: usbgecko: Use of_iomap()
On Mon, 27 Mar 2023 17:31:09 -0500, Rob Herring wrote: > Replace of_get_property()+of_translate_address()+ioremap() with a call > to of_iomap() which does all those steps. > > Applied to powerpc/next. [1/1] powerpc: usbgecko: Use of_iomap() https://git.kernel.org/powerpc/c/83a8fe569ef84d6eefcb99420a731cb87508f004 cheers
Re: [PATCH] powerpc: isa-bridge: Remove open coded "ranges" parsing
On Mon, 27 Mar 2023 17:30:45 -0500, Rob Herring wrote: > "ranges" is a standard property with common parsing functions. Users > shouldn't be implementing their own parsing of it. Reimplement the > ISA brige "ranges" parsing using the common ranges iterator functions. > > The common routines are flexible enough to work on PCI and non-PCI to > ISA bridges, so refactor pci_process_ISA_OF_ranges() and > isa_bridge_init_non_pci() into a single implementation. > > [...] Applied to powerpc/next. [1/1] powerpc: isa-bridge: Remove open coded "ranges" parsing https://git.kernel.org/powerpc/c/e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4 cheers
Re: [PATCH] powerpc: fsl_rio: Use of_iomap()
On Mon, 27 Mar 2023 17:31:02 -0500, Rob Herring wrote: > Replace of_address_to_resource()+ioremap() with a call to of_iomap() > which does both of those steps. > > Applied to powerpc/next. [1/1] powerpc: fsl_rio: Use of_iomap() https://git.kernel.org/powerpc/c/de8d11bc6ec412a498acf795911c8597ae37d4e7 cheers
Re: [PATCH] macintosh: Use of_property_present() for testing DT property presence
On Fri, 10 Mar 2023 08:47:35 -0600, Rob Herring wrote: > It is preferred to use typed property access functions (i.e. > of_property_read_ functions) rather than low-level > of_get_property/of_find_property functions for reading properties. As > part of this, convert of_get_property/of_find_property calls to the > recently added of_property_present() helper when we just want to test > for presence of a property and nothing more. > > [...] Applied to powerpc/next. [1/1] macintosh: Use of_property_present() for testing DT property presence https://git.kernel.org/powerpc/c/87b626a66dd4ab7d5caf5199d98ec0b5953d73f8 cheers
Re: [PATCH v2] macintosh: via-pmu-led: requires ATA to be set
On Wed, 22 Feb 2023 17:42:41 -0800, Randy Dunlap wrote: > LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK > when ATA is not set/enabled causes a Kconfig warning: > > WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK > Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n] > Selected by [y]: > - ADB_PMU_LED_DISK [=y] && MACINTOSH_DRIVERS [=y] && ADB_PMU_LED [=y] && > LEDS_CLASS [=y] > > [...] Applied to powerpc/next. [1/1] macintosh: via-pmu-led: requires ATA to be set https://git.kernel.org/powerpc/c/05dce4ba125336875cd3eed3c1503fa81cd2f691 cheers
Re: [PATCH] powerpc/atomics: Remove unused function
On Fri, 24 Feb 2023 16:09:40 +0530, Nysal Jan K.A wrote:
> Remove arch_atomic_try_cmpxchg_lock function as it is no longer used
> since commit 9f61521c7a28 ("powerpc/qspinlock: powerpc qspinlock
> implementation")
>
>
Applied to powerpc/next.
[1/1] powerpc/atomics: Remove unused function
https://git.kernel.org/powerpc/c/b0bbe5a2915201e3231e788d716d39dc54493b03
cheers
Re: [PATCH v3] powerpc: Implement arch_within_stack_frames
On Tue, 28 Feb 2023 05:43:55 +, Nicholas Miehlbradt wrote:
> Walks the stack when copy_{to,from}_user address is in the stack to
> ensure that the object being copied is entirely a single stack frame and
> does not contain stack metadata.
>
> Substantially similar to the x86 implementation. The back chain is used
> to traverse the stack and identify stack frame boundaries.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Implement arch_within_stack_frames
https://git.kernel.org/powerpc/c/ac9c8901cb10aab043bf3599d19eebacfcda2858
cheers
Re: [PATCH] powerpc/perf: Properly detect mpc7450 family
On Mon, 27 Feb 2023 16:54:45 +0100, Christophe Leroy wrote: > Unlike PVR_POWER8, etc , PVR_7450 represents a full PVR > value and not a family value. > > To avoid confusion, do like E500 family and define the relevant > PVR_VER_ values for the 7450 family: > 0x8000 ==> 7450 > 0x8001 ==> 7455 > 0x8002 ==> 7447 > 0x8003 ==> 7447A > 0x8004 ==> 7448 > > [...] Applied to powerpc/next. [1/1] powerpc/perf: Properly detect mpc7450 family https://git.kernel.org/powerpc/c/e7299f961fe5e4496db0bfaa9e819f5e97f3846b cheers
Re: (subset) [PATCH 0/8] RTAS changes for 6.4
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote: > Proposed changes for the RTAS subsystem and client code. > > Fixes that are subject to backporting are at the front of the queue, > followed by documentation and cleanups, with enhancements at the end. > > Noteworthy changes: > * Change sys_rtas() to consume -2/990x statuses instead of returning > them to user space. > * Lockdep annotations for invariants in rtas.c. > > [...] Applied to powerpc/next. [6/8] powerpc/rtas: lockdep annotations https://git.kernel.org/powerpc/c/af8bc68263b2184e63ee67ca70cecff4636f7901 cheers
Re: (subset) [PATCH 0/3] COVER: Remove memcpy_page_flushcache()
On Wed, 15 Mar 2023 16:20:53 -0700, Ira Weiny wrote:
> Commit 21b56c847753 ("iov_iter: get rid of separate bvec and xarray
> callbacks") removed the calls to memcpy_page_flushcache().
>
> kmap_atomic() is deprecated and used in the x86 version of
> memcpy_page_flushcache().
>
> Remove the unnecessary memcpy_page_flushcache() call from all arch's.
>
> [...]
Patch 2 applied to powerpc/next.
[2/3] powerpc: Remove memcpy_page_flushcache()
https://git.kernel.org/powerpc/c/0398abca61482ae47a41ae8f2401338aea366327
cheers
Re: [PATCH] powerpc/pseries: Add spaces around / operator
On Fri, 24 Mar 2023 23:00:41 +0100, Petr Vaněk wrote:
> This is follow up change after 14b5d59a261b ("powerpc/pseries: Fix
> formatting to make code look more beautiful") to conform to kernel
> coding style.
>
>
Applied to powerpc/next.
[1/1] powerpc/pseries: Add spaces around / operator
https://git.kernel.org/powerpc/c/2747fd26f801c98d0a8177278b4f5c91b8de9c94
cheers
Re: [PATCH 0/3] Clean up PowerPC selftest stderr output
On Tue, 28 Feb 2023 11:07:06 +1100, Benjamin Gray wrote: > There are several messages being logged to stderr when building the PowerPC > selftests: > > $ make -j$(nproc) O=build -C tools/testing/selftests \ > INSTALL_PATH="$PWD"/out/selftests TARGETS=powerpc install > /dev/null > > Makefile:50: warning: overriding recipe for target 'clean' > ../../lib.mk:124: warning: ignoring old recipe for target 'clean' > 1+0 records in > 1+0 records out > 65536 bytes (66 kB, 64 KiB) copied, 7.71e-05 s, 850 MB/s > Makefile:50: warning: overriding recipe for target 'clean' > ../../lib.mk:124: warning: ignoring old recipe for target 'clean' > make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > ... > make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > Makefile:50: warning: overriding recipe for target 'clean' > ../../lib.mk:124: warning: ignoring old recipe for target 'clean' > make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > ... > make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make > rule. > > [...] Applied to powerpc/next. [1/3] selftests/powerpc: Use CLEAN macro to fix make warning https://git.kernel.org/powerpc/c/69608683a65be5322ef44091eaeb9890472b2eea [2/3] selftests/powerpc: Pass make context to children https://git.kernel.org/powerpc/c/4ecd0868c5138238dec8a1549bb6ff8e5b48208b [3/3] selftests/powerpc: Make dd output quiet https://git.kernel.org/powerpc/c/d3cf1662b665f20444a08bff52b6daae912e0d1d cheers
Re: [PATCH] KVM: PPC: Mark three local functions "static"
On Wed, 08 Mar 2023 15:24:37 -0800, Sean Christopherson wrote: > Tag a few functions that are local and don't have a previous prototype as > "static". > > No functional change intended. > > Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Mark three local functions "static" https://git.kernel.org/powerpc/c/e83ca8cfa286c9fc78b585b0e66df7f542bcbcf2 cheers
Re: [PATCH 0/3] powerpc/kvm: Enable HV KVM guests to use prefixed instructions to access emulated MMIO
On Wed, 08 Mar 2023 17:33:43 +1100, Paul Mackerras wrote: > This series changes the powerpc KVM code so that HV KVM can fetch > prefixed instructions from the guest in those situations where there > is a need to emulate an instruction, which for HV KVM means emulating > loads and stores to emulated MMIO devices. (Prefixed instructions > were introduced with POWER10 and Power ISA v3.1, and consist of two > 32-bit words, called the prefix and the suffix.) > > [...] Applied to powerpc/topic/ppc-kvm. [1/3] powerpc/kvm: Make kvmppc_get_last_inst() produce a ppc_inst_t https://git.kernel.org/powerpc/c/acf17878da680a0c11c0bcb8a54b4f676ff39c80 [2/3] powerpc/kvm: Fetch prefixed instructions from the guest https://git.kernel.org/powerpc/c/953e37397fb61be61f095d36972188bac5235021 [3/3] powerpc/kvm: Enable prefixed instructions for HV KVM and disable for PR KVM https://git.kernel.org/powerpc/c/a3800ef9c48c4497dafe5ede1b65d91d9ef9cf1e cheers
Re: [PATCH v2 0/2] KVM: PPC: Book3S HV: Injected interrupt SRR1
On Thu, 30 Mar 2023 20:32:22 +1000, Nicholas Piggin wrote: > I missed this in my earlier review and testing, but I think we need > these in the prefix instruction enablement series before the final patch > that enables HFSCR[PREFIX] for guests. > > Thanks, > Nick > > [...] Applied to powerpc/topic/ppc-kvm. [1/2] KVM: PPC: Permit SRR1 flags in more injected interrupt types https://git.kernel.org/powerpc/c/460ba21d83fef766a5d34260e464c9ab8f10aa05 [2/2] KVM: PPC: Book3S HV: Set SRR1[PREFIX] bit on injected interrupts https://git.kernel.org/powerpc/c/6cd5c1db9983600f1848822e86e4906377b4a899 cheers
Re: [PATCH v2] KVM: PPC: BookE: Fix W=1 warnings
On Mon, 03 Apr 2023 14:53:14 +1000, Michael Ellerman wrote: > Fix various W=1 warnings in booke.c: > > arch/powerpc/kvm/booke.c:1008:5: error: no previous prototype for > ‘kvmppc_handle_exit’ [-Werror=missing-prototypes] >1008 | int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr) > | ^~ > arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member 'vcpu' > not described in 'kvmppc_handle_exit' > arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member > 'exit_nr' not described in 'kvmppc_handle_exit' > > [...] Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: BookE: Fix W=1 warnings https://git.kernel.org/powerpc/c/43d05c6123ca1ace5982ca326c156502e735b7d5 cheers
Re: [PATCH v5] KVM: PPC: Book3S HV: kvmppc_hv_entry: remove .global scope
On Mon, 27 Mar 2023 07:33:20 -0400, Kautuk Consul wrote: > kvmppc_hv_entry isn't called from anywhere other than > book3s_hv_rmhandlers.S itself. Removing .global scope for > this function and annotating it with SYM_CODE_START_LOCAL > and SYM_CODE_END. > > Applied to powerpc/topic/ppc-kvm. [1/1] KVM: PPC: Book3S HV: kvmppc_hv_entry: remove .global scope https://git.kernel.org/powerpc/c/5f4f53d28cde2cc7be96f657229c8603da578500 cheers
Re: [PATCH] powerpc/mm: Fix false detection of read faults
On Fri, 10 Mar 2023 16:08:34 +1100, Russell Currey wrote: > To support detection of read faults with Radix execute-only memory, the > vma_is_accessible() check in access_error() (which checks for PROT_NONE) > was replaced with a check to see if VM_READ was missing, and if so, > returns true to assert the fault was caused by a bad read. > > This is incorrect, as it ignores that both VM_WRITE and VM_EXEC imply > read on powerpc, as defined in protection_map[]. This causes mappings > containing VM_WRITE or VM_EXEC without VM_READ to misreport the cause of > page faults, since the MMU is still allowing reads. > > [...] Applied to powerpc/fixes. [1/1] powerpc/mm: Fix false detection of read faults https://git.kernel.org/powerpc/c/f2c7e3562b4c4f1699acc1538ebf3e75f5cced35 cheers
Re: [PATCH v2] powerpc/pseries/vas: Ignore VAS update for DLPAR if copy/paste is not enabled
On Mon, 20 Mar 2023 19:50:08 -0700, Haren Myneni wrote: > The hypervisor supports user-mode NX from Power10. pseries_vas_dlpar_cpu() > is called from lparcfg_write() to update VAS windows for DLPAR event in > shared processor mode and the kernel gets -ENOTSUPP for HCALLs if the > user-mode NX is not supported. The current VAS implementation also > supports only with Radix page tables. Whereas in dedicated processor > mode, pseries_vas_notifier() is registered only if the copy/paste > feature is enabled. So instead of displaying HCALL error messages, > update VAS capabilities if the copy/paste feature is available. > > [...] Applied to powerpc/fixes. [1/1] powerpc/pseries/vas: Ignore VAS update for DLPAR if copy/paste is not enabled https://git.kernel.org/powerpc/c/eca9f6e6f83b6725b84e1c76fdde19b003cff0eb cheers
Re: [PATCH v2] powerpc/64s: Fix __pte_needs_flush() false positive warning
On Fri, 03 Mar 2023 09:59:47 +1100, Benjamin Gray wrote: > Userspace PROT_NONE ptes set _PAGE_PRIVILEGED, triggering a false > positive debug assertion that __pte_flags_need_flush() is not called > on a kernel mapping. > > Detect when it is a userspace PROT_NONE page by checking the required > bits of PAGE_NONE are set, and none of the RWX bits are set. > pte_protnone() is insufficient here because it always returns 0 when > CONFIG_NUMA_BALANCING=n. > > [...] Applied to powerpc/fixes. [1/1] powerpc/64s: Fix __pte_needs_flush() false positive warning https://git.kernel.org/powerpc/c/1abce0580b89464546ae06abd5891ebec43c9470 cheers
Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs
On Sun, 26 Mar 2023 16:15:57 -0600, Jens Axboe wrote: > Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which > from my (arguably very short) checking is not commonly done for other > archs. This is fine, except when PF_IO_WORKER's have been created and > the task does something that causes a coredump to be generated. Then we > get this crash: > > [...] Applied to powerpc/fixes. [1/1] powerpc: don't try to copy ppc for task with NULL pt_regs https://git.kernel.org/powerpc/c/fd7276189450110ed835eb0a334e62d2f1c4e3be cheers
Re: [PATCH v2] powerpc/papr_scm: Update the NUMA distance table for the target node
On Tue, 04 Apr 2023 09:44:33 +0530, Aneesh Kumar K.V wrote: > platform device helper routines won't update the NUMA distance table > while creating a platform device, even if the device is present on > a NUMA node that doesn't have memory or CPU. This is especially true > for pmem devices. If the target node of the pmem device is not online, we > find the nearest online node to the device and associate the pmem > device with that online node. To find the nearest online node, we should > have the numa distance table updated correctly. Update the distance > information during the device probe. > > [...] Applied to powerpc/fixes. [1/1] powerpc/papr_scm: Update the NUMA distance table for the target node https://git.kernel.org/powerpc/c/b277fc793daf258877b4c0744b52f69d6e6ba22e cheers
Re: Probing nvme disks fails on Upstream kernels on powerpc Maxconfig
"Linux regression tracking (Thorsten Leemhuis)" writes: > [CCing the regression list, as it should be in the loop for regressions: > https://docs.kernel.org/admin-guide/reporting-regressions.html] > > On 23.03.23 10:53, Srikar Dronamraju wrote: >> >> I am unable to boot upstream kernels from v5.16 to the latest upstream >> kernel on a maxconfig system. (Machine config details given below) >> >> At boot, we see a series of messages like the below. >> >> dracut-initqueue[13917]: Warning: dracut-initqueue: timeout, still waiting >> for following initqueue hooks: >> dracut-initqueue[13917]: Warning: >> /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-uuid\x2f93dc0767-18aa-467f-afa7-5b4e9c13108a.sh: >> "if ! grep -q After=remote-fs-pre.target >> /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then >> dracut-initqueue[13917]: [ -e >> "/dev/disk/by-uuid/93dc0767-18aa-467f-afa7-5b4e9c13108a" ] >> dracut-initqueue[13917]: fi" > > Alexey, did you look into this? This is apparently caused by a commit of > yours (see quoted part below) that Michael applied. Looks like it fell > through the cracks from here, but maybe I'm missing something. Unfortunately Alexey is not working at IBM any more, so he won't have access to any hardware to debug/test this. Srikar are you debugging this? If not we'll have to find someone else to look at it. cheers
Re: [PATCH] powerpc/64: Always build with 128-bit long double
Segher Boessenkool writes: > On Tue, Apr 04, 2023 at 08:28:47PM +1000, Michael Ellerman wrote: >> The amdgpu driver builds some of its code with hard-float enabled, >> whereas the rest of the kernel is built with soft-float. >> >> When building with 64-bit long double, if soft-float and hard-float >> objects are linked together, the build fails due to incompatible ABI >> tags. > >> Currently those build errors are avoided because the amdgpu driver is >> gated on 128-bit long double being enabled. But that's not a detail the >> amdgpu driver should need to be aware of, and if another driver starts >> using hard-float the same problem would occur. > > Well. The kernel driver either has no business using long double (or > any other floating point even) at all, or it should know exactly what is > used: double precision, double-double, or quadruple precision. Both of > the latter two are 128 bits. In a perfect world ... :) >> All versions of the 64-bit ABI specify that long-double is 128-bits. >> However some compilers, notably the kernel.org ones, are built to use >> 64-bit long double by default. > > Mea culpa, I suppose? But builddall doesn't force 64 bit explicitly. > I wonder how this happened? Is it maybe a problem in the powerpc64le > config in GCC itself? Not blaming anyone, just one of those things that happens. The toolchains the distros (Ubuntu/Fedora) build all seem to use 128, but possibly that's because someone told them to configure them that way at some point. > I have a patch from summer last year (Arnd's > toolchains are built without it) that does > + powerpc64le-*) TARGET_GCC_CONF=--with-long-double-128 > Unfortunately I don't remember why I did that, and I never investigated > what the deeper problem is :-/ Last summer (aka winter) is when we first discovered this issue with the long double size being implicated. See: https://git.kernel.org/torvalds/c/c653c591789b3acfa4bf6ae45d5af4f330e50a91 So I guess that's what prompted your patch? > In either case, the kernel should always use specific types, not rely on > the toolchain to pick a type that may or may not work. The correct size > floating point type alone is not enough, but it is a step in the right > direction certainly. > > Reviewed-by: Segher Boessenkool Thanks. cheers
[PATCH] powerpc/64: Always build with 128-bit long double
The amdgpu driver builds some of its code with hard-float enabled,
whereas the rest of the kernel is built with soft-float.
When building with 64-bit long double, if soft-float and hard-float
objects are linked together, the build fails due to incompatible ABI
tags.
In the past there have been build errors in the amdgpu driver caused by
this, some of those were due to bad intermingling of soft & hard-float
code, but those issues have now all been fixed since commit c92b7fe0d92a
("drm/amd/display: move remaining FPU code to dml folder").
However it's still possible for soft & hard-float objects to end up
linked together, if the amdgpu driver is built-in to the kernel along
with the test_emulate_step.c code, which uses soft-float. That happens
in an allyesconfig build.
Currently those build errors are avoided because the amdgpu driver is
gated on 128-bit long double being enabled. But that's not a detail the
amdgpu driver should need to be aware of, and if another driver starts
using hard-float the same problem would occur.
All versions of the 64-bit ABI specify that long-double is 128-bits.
However some compilers, notably the kernel.org ones, are built to use
64-bit long double by default.
Apart from this issue of soft vs hard-float, the kernel doesn't care
what size long double is. In particular the kernel using 128-bit long
double doesn't impact userspace's ability to use 64-bit long double, as
musl does.
So always build the 64-bit kernel with 128-bit long double. That should
avoid any build errors due to the incompatible ABI tags. Excluding the
code that uses soft/hard-float, the vmlinux is identical with/without
the flag.
It does mean any code which is incorrectly intermingling soft &
hard-float code will build without error, so those bugs will need to be
caught by testing rather than at build time.
For more background see:
- commit d11219ad53dc ("amdgpu: disable powerpc support for the newer display
engine")
- commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
-
https://lore.kernel.org/r/dab9cbd8-2626-4b99-8098-31fe76397...@app.fastmail.com
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig| 4
arch/powerpc/Makefile | 1 +
drivers/gpu/drm/amd/display/Kconfig | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fc4e81dafca7..3fb2c2766139 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -291,10 +291,6 @@ config PPC
# Please keep this list sorted alphabetically.
#
-config PPC_LONG_DOUBLE_128
- depends on PPC64 && ALTIVEC
- def_bool $(success,test "$(shell,echo __LONG_DOUBLE_128__ | $(CC) -E -P
-)" = 1)
-
config PPC_BARRIER_NOSPEC
bool
default y
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 12447b2361e4..4343cca57cb3 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,6 +133,7 @@ endif
endif
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call
cc-option,-mminimal-toc))
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions)
+CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128)
# Clang unconditionally reserves r2 on ppc32 and does not support the flag
# https://bugs.llvm.org/show_bug.cgi?id=39555
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 0c9bd0a53e60..e36261d546af 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -8,7 +8,7 @@ config DRM_AMD_DC
depends on BROKEN || !CC_IS_CLANG || X86_64 || SPARC64 || ARM64
select SND_HDA_COMPONENT if SND_HDA_CORE
# !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752
- select DRM_AMD_DC_DCN if (X86 || PPC_LONG_DOUBLE_128 || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
+ select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 &&
KERNEL_MODE_NEON && !CC_IS_CLANG))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
--
2.39.2
[PATCH v2] KVM: PPC: BookE: Fix W=1 warnings
Fix various W=1 warnings in booke.c:
arch/powerpc/kvm/booke.c:1008:5: error: no previous prototype for
‘kvmppc_handle_exit’ [-Werror=missing-prototypes]
1008 | int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr)
| ^~
arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member 'vcpu'
not described in 'kvmppc_handle_exit'
arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member
'exit_nr' not described in 'kvmppc_handle_exit'
Reported-by: kernel test robot
Link: https://lore.kernel.org/r/202304020827.3lez86wb-...@intel.com/
Signed-off-by: Michael Ellerman
---
arch/powerpc/kvm/booke.c | 2 +-
arch/powerpc/kvm/booke.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
v2: Rebased on my topic/ppc-kvm branch where I already had some of the
fixes queued.
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ce37d282be6d..a9c04073d27e 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1000,7 +1000,7 @@ static int kvmppc_resume_inst_load(struct kvm_vcpu *vcpu,
}
}
-/**
+/*
* kvmppc_handle_exit
*
* Return value is in the form (errcode<<2 | RESUME_FLAG_HOST | RESUME_FLAG_NV)
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index be9da96d9f06..9c5b8e76014f 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -109,4 +109,7 @@ static inline void kvmppc_clear_dbsr(void)
{
mtspr(SPRN_DBSR, mfspr(SPRN_DBSR));
}
+
+int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr);
+
#endif /* __KVM_BOOKE_H__ */
--
2.39.2
[PATCH] KVM: PPC: BookE: Fix W=1 warnings
Fix various W=1 warnings in booke.c:
arch/powerpc/kvm/booke.c:626:6: error: no previous prototype for
‘kvmppc_watchdog_func’ [-Werror=missing-prototypes]
626 | void kvmppc_watchdog_func(struct timer_list *t)
| ^~~~
arch/powerpc/kvm/booke.c:1008:5: error: no previous prototype for
‘kvmppc_handle_exit’ [-Werror=missing-prototypes]
1008 | int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr)
| ^~
arch/powerpc/kvm/booke.c:1949:6: error: no previous prototype for
‘kvm_guest_protect_msr’ [-Werror=missing-prototypes]
1949 | void kvm_guest_protect_msr(struct kvm_vcpu *vcpu, ulong prot_bitmap,
bool set)
| ^
arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member 'vcpu'
not described in 'kvmppc_handle_exit'
arch/powerpc/kvm/booke.c:1009: warning: Function parameter or member
'exit_nr' not described in 'kvmppc_handle_exit'
Reported-by: kernel test robot
Link: https://lore.kernel.org/r/202304020827.3lez86wb-...@intel.com/
Signed-off-by: Michael Ellerman
---
arch/powerpc/kvm/booke.c | 7 ---
arch/powerpc/kvm/booke.h | 3 +++
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 01adffb24667..5908f2cc6a81 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -623,7 +623,7 @@ static void arm_next_watchdog(struct kvm_vcpu *vcpu)
spin_unlock_irqrestore(>arch.wdt_lock, flags);
}
-void kvmppc_watchdog_func(struct timer_list *t)
+static void kvmppc_watchdog_func(struct timer_list *t)
{
struct kvm_vcpu *vcpu = from_timer(vcpu, t, arch.wdt_timer);
u32 tsr, new_tsr;
@@ -1000,7 +1000,7 @@ static int kvmppc_resume_inst_load(struct kvm_vcpu *vcpu,
}
}
-/**
+/*
* kvmppc_handle_exit
*
* Return value is in the form (errcode<<2 | RESUME_FLAG_HOST | RESUME_FLAG_NV)
@@ -1946,7 +1946,8 @@ static int kvmppc_booke_add_watchpoint(struct debug_reg
*dbg_reg, uint64_t addr,
dbg_reg->dbcr0 |= DBCR0_IDM;
return 0;
}
-void kvm_guest_protect_msr(struct kvm_vcpu *vcpu, ulong prot_bitmap, bool set)
+
+static void kvm_guest_protect_msr(struct kvm_vcpu *vcpu, ulong prot_bitmap,
bool set)
{
/* XXX: Add similar MSR protection for BookE-PR */
#ifdef CONFIG_KVM_BOOKE_HV
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index be9da96d9f06..9c5b8e76014f 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -109,4 +109,7 @@ static inline void kvmppc_clear_dbsr(void)
{
mtspr(SPRN_DBSR, mfspr(SPRN_DBSR));
}
+
+int kvmppc_handle_exit(struct kvm_vcpu *vcpu, unsigned int exit_nr);
+
#endif /* __KVM_BOOKE_H__ */
--
2.39.2
[GIT PULL] Please pull powerpc/linux.git powerpc-6.3-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 6.3: The following changes since commit f2c7e3562b4c4f1699acc1538ebf3e75f5cced35: powerpc/mm: Fix false detection of read faults (2023-03-15 20:48:53 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.3-4 for you to fetch changes up to eca9f6e6f83b6725b84e1c76fdde19b003cff0eb: powerpc/pseries/vas: Ignore VAS update for DLPAR if copy/paste is not enabled (2023-03-29 23:01:35 +1100) - -- powerpc fixes for 6.3 #4 - Fix a false positive warning in __pte_needs_flush() (with DEBUG_VM=y). - Fix oops when a PF_IO_WORKER thread tries to core dump. - Don't try to reconfigure VAS when it's disabled. Thanks to: Benjamin Gray, Haren Myneni, Jens Axboe, Nathan Lynch, Russell Currey. - -- Benjamin Gray (1): powerpc/64s: Fix __pte_needs_flush() false positive warning Haren Myneni (1): powerpc/pseries/vas: Ignore VAS update for DLPAR if copy/paste is not enabled Jens Axboe (1): powerpc: Don't try to copy PPR for task with NULL pt_regs arch/powerpc/include/asm/book3s/64/tlbflush.h | 9 +++-- arch/powerpc/kernel/ptrace/ptrace-view.c | 6 ++ arch/powerpc/platforms/pseries/vas.c | 8 3 files changed, 21 insertions(+), 2 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmQpU+AACgkQUevqPMjh pYAtgw//bMBbJvHS3zysyA4ADuISc5asa73axQJ8UK9je0UqeprA6z+DEocFIY+w Tr6J4/0ynX5fbtAGOBQfaiiv3bhRzsZF7XFo6dw+Gy7kqPshjaF7hR/By4jNcva4 pM84AKaPQAnkeOntkxkExSWYyWLA7sjYlLdkPxnoifqH3WELOLCas9Be9NmUgKDi kcspsRVeTdVlQuRS+mVJ62AHixfBz1ZmZcq9i1m4vrhvajlWtfp1TKb7xjIBAydL el3yiNPlQa5W2aLuJM/+i/33Fik89jJ8muUssMIBL+1rVVzFcoLY/f/Tbo7i4ex1 +kwtSGRdp5N9EZglpUSmQobe/fc1dmx52aa0HFpnIpUKbd62oeKrAtvNowVx+UGa zU5keDwCqUysweGtfDbIrn12828CQV50hywgwkF0r6wv2dqaJ6NVRWMsnGIFumV4 6i2ZLc014ixdju6xdL67hFPUl0WU/Nx+T9kKT1+9qEzOvsR9SUS8TuMcQkfNs7JL zueSYJM3yf7J/EqKroyqnDgsR+UWApMMuOfXjEEeDLTAoGpzY2RdJ5Zh8tej7S7o lAKbQC2s3g2/amNmySr9D19YWXAmQBaxk3t10J2Jvj5ccVlNMbrwjfrNFxOats2L ZHELf7F/O9x5X21BpWypHKGZWq7GJx1uYGArGHgBjCrEUNR+7Aw= =sL3a -END PGP SIGNATURE-
Re: [PATCH] drm/amdgpu: drop the long-double-128 powerpc check/hack
"Daniel Kolesa" writes:
> Commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
> introduced this check as a workaround for the driver not building
> with toolchains that default to 64-bit long double.
...
> In mainline, this work is now fully done, so this check is fully
> redundant and does not do anything except preventing AMDGPU DC
> from being built on systems such as those using musl libc. The
> last piece of work to enable this was commit c92b7fe0d92a
> ("drm/amd/display: move remaining FPU code to dml folder")
> and this has since been backported to 6.1 stable (in 6.1.7).
>
> Relevant issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2288
I looked to pick this up for 6.3 but was still seeing build errors with
some compilers. I assumed that was due to some fixes coming in
linux-next that I didn't have.
But applying the patch on v6.3-rc4 I still see build errors. This is
building allyesconfig with the kernel.org GCC 12.2.0 / binutils 2.39
toolchain:
powerpc64le-linux-gnu-ld:
drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o uses hard float,
arch/powerpc/lib/test_emulate_step.o uses soft float
powerpc64le-linux-gnu-ld: failed to merge target specific data of file
drivers/gpu/drm/amd/display/dc/dml/display_mode_lib.o
etc.
All the conflicts are between test_emulate_step.o and some file in
drivers/gpu/drm/amd/display/dc/dml.
So even with all the hard-float code isolated in the dml folder, we
still hit build errors, because allyesconfig wants to link those
hard-float using objects with soft-float objects from elsewhere in the
kernel.
It seems like the only workable fix is to force the kernel build to use
128-bit long double. I'll send a patch doing that.
cheers
Re: [PATCH v8 0/7] Support page table check
Rohan McLure writes:
> Anyone got time to review this one?
I was planning to pick it up, but it's going to conflict badly with the
set_ptes() series:
https://lore.kernel.org/all/20230315051444.3229621-1-wi...@infradead.org/
I thought that series was likely to go in soon, but I see it's still not
in linux-next.
Hopefully there'll be a v5 of that series soon and we can try and work
out the conflicts. I might need to create a topic branch, or have this
series go via -mm.
cheers
>> On 16 Feb 2023, at 10:11 am, Rohan McLure wrote:
>>
>> Support the page table check sanitiser on all PowerPC platforms. This
>> sanitiser works by serialising assignments, reassignments and clears of
>> page table entries at each level in order to ensure that anonymous
>> mappings have at most one writable consumer, and likewise that
>> file-backed mappings are not simultaneously also anonymous mappings.
>>
>> In order to support this infrastructure, a number of stubs must be
>> defined for all powerpc platforms. Additionally, seperate set_pte_at
>> and set_pte, to allow for internal, uninstrumented mappings.
>>
>> v8:
>> * Fix linux/page_table_check.h include in asm/pgtable.h breaking
>> 32-bit.
>>
>> v7:
>> * Remove use of extern in set_pte prototypes
>> * Clean up pmdp_collapse_flush macro
>> * Replace set_pte_at with static inline function
>> * Fix commit message for patch 7
>> Link:
>> https://lore.kernel.org/linuxppc-dev/20230215020155.1969194-1-rmcl...@linux.ibm.com/
>>
>> v6:
>> * Support huge pages and p{m,u}d accounting.
>> * Remove instrumentation from set_pte from kernel internal pages.
>> * 64s: Implement pmdp_collapse_flush in terms of __pmdp_collapse_flush
>> as access to the mm_struct * is required.
>> Link:
>> https://lore.kernel.org/linuxppc-dev/20230214015939.1853438-1-rmcl...@linux.ibm.com/
>>
>> v5:
>> Link:
>> https://lore.kernel.org/linuxppc-dev/20221118002146.25979-1-rmcl...@linux.ibm.com/
>>
>> Rohan McLure (7):
>> powerpc: mm: Separate set_pte, set_pte_at for internal, external use
>> powerpc/64s: mm: Introduce __pmdp_collapse_flush with mm_struct
>>argument
>> powerpc: mm: Replace p{u,m,4}d_is_leaf with p{u,m,4}_leaf
>> powerpc: mm: Implement p{m,u,4}d_leaf on all platforms
>> powerpc: mm: Add common pud_pfn stub for all platforms
>> powerpc: mm: Add p{te,md,ud}_user_accessible_page helpers
>> powerpc: mm: Support page table check
>>
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/book3s/32/pgtable.h | 17 +++-
>> arch/powerpc/include/asm/book3s/64/pgtable.h | 85 +---
>> arch/powerpc/include/asm/book3s/pgtable.h| 3 +-
>> arch/powerpc/include/asm/nohash/32/pgtable.h | 12 ++-
>> arch/powerpc/include/asm/nohash/64/pgtable.h | 24 +-
>> arch/powerpc/include/asm/nohash/pgtable.h| 9 ++-
>> arch/powerpc/include/asm/pgtable.h | 60 +-
>> arch/powerpc/kvm/book3s_64_mmu_radix.c | 12 +--
>> arch/powerpc/mm/book3s64/hash_pgtable.c | 2 +-
>> arch/powerpc/mm/book3s64/pgtable.c | 16 ++--
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 24 +++---
>> arch/powerpc/mm/nohash/book3e_pgtable.c | 2 +-
>> arch/powerpc/mm/pgtable.c| 9 +--
>> arch/powerpc/mm/pgtable_32.c | 2 +-
>> arch/powerpc/mm/pgtable_64.c | 6 +-
>> arch/powerpc/xmon/xmon.c | 6 +-
>> 17 files changed, 197 insertions(+), 93 deletions(-)
>>
>> --
>> 2.37.2
>>
Re: [PATCH] arch/powerpc/kvm: kvmppc_core_vcpu_create_hv: check for kzalloc failure
Kautuk Consul writes:
> On 2023-03-28 23:02:09, Michael Ellerman wrote:
>> Kautuk Consul writes:
>> > On 2023-03-28 15:44:02, Kautuk Consul wrote:
>> >> On 2023-03-28 20:44:48, Michael Ellerman wrote:
>> >> > Kautuk Consul writes:
>> >> > > kvmppc_vcore_create() might not be able to allocate memory through
>> >> > > kzalloc. In that case the kvm->arch.online_vcores shouldn't be
>> >> > > incremented.
>> >> >
>> >> > I agree that looks wrong.
>> >> >
>> >> > Have you tried to test what goes wrong if it fails? It looks like it
>> >> > will break the LPCR update, which likely will cause the guest to crash
>> >> > horribly.
>> > Also, are you referring to the code in kvmppc_update_lpcr()?
>> > That code will not crash as it checks for the vc before trying to
>> > dereference it.
>>
>> Yeah that's what I was looking at. I didn't mean it would crash, but
>> that it would bail out early when it sees a NULL vcore, leaving other
>> vcores with the wrong LPCR value.
>>
>> But as you say it doesn't happen because qemu quits on the first ENOMEM.
>>
>> And regardless if qemu does something that means the guest is broken
>> that's just a qemu bug, no big deal as far as the kernel is concerned.
> But there could be another user-mode application other than qemu that
> actually tries to create a vcpu after it gets a -ENOMEM for another
> vcpu. Shouldn't the kernel be independent of qemu?
Yes, the kernel is independent of qemu.
On P8 we had kvmtool, and there's several other VMMs these days, though
most don't support Power.
I didn't mean qemu specifically above. If any VMM continues blindly
after getting ENOMEM back from the KVM API then that's a bug in that
VMM.
>> > But the following 2 places that utilize the arch.online_vcores will have
>> > problems in logic if the usermode test-case doesn't pull down the
>> > kvm context after the -ENOMEM vcpu allocation failure:
>> > book3s_hv.c:3030: if (!kvm->arch.online_vcores) {
>> > book3s_hv_rm_mmu.c:44: if (kvm->arch.online_vcores == 1 &&
>> > local_paca->kvm_hstate.kvm_vcpu)
>>
>> OK. Both of those look harmless to the host.
> Harmless to the host in terms of a crash, not in terms of behavior.
> For example in the case of kvmhv_set_smt_mode:
> If we got a kzalloc failure once (and online_vcores was wrongly incremented),
> then if kvmhv_set_smt_mode() is called after that then it would be
> not be setting the arch.smt_mode and arch.emul_smt_mode correctly and it
> would be wrongly returning with -EBUSY instead of 0.
But again that bug only affects that VM, which the VMM should have
terminated when it got the ENOMEM back.
It's definitely a bug that we increment online_vcores incorrectly, but
it only affects that VM, and a correctly operating VMM will terminate
the VM anyway because of the ENOMEM.
cheers
[PATCH] powerpc/64s: Move CPU -mtune options into Kconfig
Currently the -mtune options are set in the Makefile, depending on what the compiler supports. One downside of doing it that way is that the chosen -mtune option is not recorded in the .config. Another downside is that if there's ever a need to do more complicated logic to calculate the correct option, that gets messy in the Makefile. So move the determination of which -mtune option to use into Kconfig logic. Signed-off-by: Michael Ellerman --- arch/powerpc/Makefile | 4 +--- arch/powerpc/platforms/Kconfig.cputype | 7 +++ 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 87d6ac27eebd..779956007f0c 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -156,9 +156,7 @@ endif CFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) AFLAGS-$(CONFIG_TARGET_CPU_BOOL) += -mcpu=$(CONFIG_TARGET_CPU) -CFLAGS-$(CONFIG_POWERPC64_CPU) += $(call cc-option,-mtune=power10, \ - $(call cc-option,-mtune=power9, \ - $(call cc-option,-mtune=power8))) +CFLAGS-y += $(CONFIG_TUNE_CPU) asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index 046b571496b1..76d6daa6c79d 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -273,6 +273,13 @@ config TARGET_CPU default "e500mc" if E500MC_CPU default "powerpc" if POWERPC_CPU +config TUNE_CPU + string + depends on POWERPC64_CPU + default "-mtune=power10" if $(cc-option,-mtune=power10) + default "-mtune=power9" if $(cc-option,-mtune=power9) + default "-mtune=power8" if $(cc-option,-mtune=power8) + config PPC_BOOK3S def_bool y depends on PPC_BOOK3S_32 || PPC_BOOK3S_64 -- 2.39.2
Re: [PATCH 5/8] powerpc/rtas: rename va_rtas_call_unlocked() to va_rtas_call()
Nathan Lynch via B4 Relay writes: > From: Nathan Lynch > > The function name va_rtas_call_unlocked() is confusing: it may be > called with or without rtas_lock held. Rename it to va_rtas_call(). I'm not sure about this one. The "unlocked" is meant to convey that it doesn't do any locking. The caller has to be OK with that, or do its own locking. Andrew is right that the common naming pattern is foo() that takes the lock and __foo() that doesn't - but I agree that's not very pretty. Can we just leave it as-is? cheers
Re: [PATCH 7/8] powerpc/rtas: warn on unsafe argument to rtas_call_unlocked()
Nathan Lynch writes: > Nathan Lynch writes: >> >> aside: does anyone know if the display_status() code is worth keeping? >> It looks like it is used to drive the 16-character wide physical LCD I >> remember seeing on P4-era and older machines. Is it a vestige of >> non-LPAR pseries that should be dropped, or is it perhaps useful for >> chrp or cell? > > Never mind, I see the display-character token and associated properties > on a P8 LPAR and in a current PAPR. Or a P10 LPAR even. The characters written using it are shown on the HMC, somewhere on the partition info page. cheers
[PATCH 1/2] powerpc/Makefile: Don't prefix archhelp commands with "@"
It's not necessary to prefix every command in archhelp with "@" (to supress echoing the command), because that is done by the top level Makefile when it evaluates archhelp. Signed-off-by: Michael Ellerman --- arch/powerpc/Makefile | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index dc4cbf0a5ca9..b9bfa9ac3f06 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -349,25 +349,25 @@ PHONY += ppc64_randconfig -f $(srctree)/Makefile randconfig define archhelp - @echo '* zImage - Build default images selected by kernel config' - @echo ' zImage.*- Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' - @echo ' uImage - U-Boot native image format' - @echo ' cuImage.- Backwards compatible U-Boot image for older' - @echo 'versions which do not support device trees' - @echo ' dtbImage. - zImage with an embedded device tree blob' - @echo ' simpleImage. - Firmware independent image.' - @echo ' treeImage. - Support for older IBM 4xx firmware (not U-Boot)' - @echo ' install - Install kernel using' - @echo '(your) ~/bin/$(INSTALLKERNEL) or' - @echo '(distribution) /sbin/$(INSTALLKERNEL) or' - @echo 'install to $$(INSTALL_PATH) and run lilo' - @echo ' *_defconfig - Select default config from arch/$(ARCH)/configs' - @echo '' - @echo ' Targets with embed a device tree blob inside the image' - @echo ' These targets support board with firmware that does not' - @echo ' support passing a device tree directly. Replace with the' - @echo ' name of a dts file from the arch/$(ARCH)/boot/dts/ directory' - @echo ' (minus the .dts extension).' + echo '* zImage - Build default images selected by kernel config' + echo ' zImage.*- Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' + echo ' uImage - U-Boot native image format' + echo ' cuImage.- Backwards compatible U-Boot image for older' + echo 'versions which do not support device trees' + echo ' dtbImage. - zImage with an embedded device tree blob' + echo ' simpleImage. - Firmware independent image.' + echo ' treeImage. - Support for older IBM 4xx firmware (not U-Boot)' + echo ' install - Install kernel using' + echo '(your) ~/bin/$(INSTALLKERNEL) or' + echo '(distribution) /sbin/$(INSTALLKERNEL) or' + echo 'install to $$(INSTALL_PATH) and run lilo' + echo ' *_defconfig - Select default config from arch/$(ARCH)/configs' + echo '' + echo ' Targets with embed a device tree blob inside the image' + echo ' These targets support board with firmware that does not' + echo ' support passing a device tree directly. Replace with the' + echo ' name of a dts file from the arch/$(ARCH)/boot/dts/ directory' + echo ' (minus the .dts extension).' endef PHONY += install -- 2.39.2
[PATCH 2/2] powerpc/Makefile: Add generated defconfigs to help output
Currently none of the generated defconfigs appear in the help output, because the help text discovers defconfigs by looking for actual files named "*_defconfig". Collect the generated defconfig names into a variable and then print those out in archhelp. Output looks like eg: pseries_le_defconfig- Build for pseries_le ppc64le_defconfig - Build for ppc64le ppc64le_guest_defconfig - Build for ppc64le_guest ... ppc64_randconfig- Build for ppc64_randconfig adder875_defconfig - Build for adder875 amigaone_defconfig - Build for amigaone Signed-off-by: Michael Ellerman --- arch/powerpc/Makefile | 41 +++-- 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index b9bfa9ac3f06..0a99aa425326 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -264,90 +264,92 @@ define merge_into_defconfig +$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig endef -PHONY += pseries_le_defconfig +generated_configs += pseries_le_defconfig pseries_le_defconfig: $(call merge_into_defconfig,pseries_defconfig,le) -PHONY += ppc64le_defconfig +generated_configs += ppc64le_defconfig ppc64le_defconfig: $(call merge_into_defconfig,ppc64_defconfig,le) -PHONY += ppc64le_guest_defconfig +generated_configs += ppc64le_guest_defconfig ppc64le_guest_defconfig: $(call merge_into_defconfig,ppc64_defconfig,le guest) -PHONY += ppc64_guest_defconfig +generated_configs += ppc64_guest_defconfig ppc64_guest_defconfig: $(call merge_into_defconfig,ppc64_defconfig,be guest) -PHONY += powernv_be_defconfig +generated_configs += powernv_be_defconfig powernv_be_defconfig: $(call merge_into_defconfig,powernv_defconfig,be) -PHONY += mpc85xx_defconfig +generated_configs += mpc85xx_defconfig mpc85xx_defconfig: $(call merge_into_defconfig,mpc85xx_base.config,\ 85xx-32bit 85xx-hw fsl-emb-nonhw) -PHONY += mpc85xx_smp_defconfig +generated_configs += mpc85xx_smp_defconfig mpc85xx_smp_defconfig: $(call merge_into_defconfig,mpc85xx_base.config,\ 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw) -PHONY += corenet32_smp_defconfig +generated_configs += corenet32_smp_defconfig corenet32_smp_defconfig: $(call merge_into_defconfig,corenet_base.config,\ 85xx-32bit 85xx-smp 85xx-hw fsl-emb-nonhw dpaa) -PHONY += corenet64_smp_defconfig +generated_configs += corenet64_smp_defconfig corenet64_smp_defconfig: $(call merge_into_defconfig,corenet_base.config,\ 85xx-64bit 85xx-smp altivec 85xx-hw fsl-emb-nonhw dpaa) -PHONY += mpc86xx_defconfig +generated_configs += mpc86xx_defconfig mpc86xx_defconfig: $(call merge_into_defconfig,mpc86xx_base.config,\ 86xx-hw fsl-emb-nonhw) -PHONY += mpc86xx_smp_defconfig +generated_configs += mpc86xx_smp_defconfig mpc86xx_smp_defconfig: $(call merge_into_defconfig,mpc86xx_base.config,\ 86xx-smp 86xx-hw fsl-emb-nonhw) -PHONY += ppc32_allmodconfig +generated_configs += ppc32_allmodconfig ppc32_allmodconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/book3s_32.config \ -f $(srctree)/Makefile allmodconfig -PHONY += ppc_defconfig +generated_configs += ppc_defconfig ppc_defconfig: $(call merge_into_defconfig,book3s_32.config,) -PHONY += ppc64le_allmodconfig +generated_configs += ppc64le_allmodconfig ppc64le_allmodconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/le.config \ -f $(srctree)/Makefile allmodconfig -PHONY += ppc64le_allnoconfig +generated_configs += ppc64le_allnoconfig ppc64le_allnoconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/ppc64le.config \ -f $(srctree)/Makefile allnoconfig -PHONY += ppc64_book3e_allmodconfig +generated_configs += ppc64_book3e_allmodconfig ppc64_book3e_allmodconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/85xx-64bit.config \ -f $(srctree)/Makefile allmodconfig -PHONY += ppc32_randconfig +generated_configs += ppc32_randconfig ppc32_randconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/32-bit.config \ -f $(srctree)/Makefile randconfig -PHONY += ppc64_randconfig +generated_configs += ppc64_randconfig ppc64_randconfig: $(Q)$(MAKE) KCONFIG_ALLCONFIG=$(srctree)/arch/powerpc/configs/64-bit.config \ -f $(srctree)/Makefile randconfig +PHONY := $(generated_configs) + define archhelp echo '* zImage - Build default images selected by kernel config' echo ' zImage.*- Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' @@ -368,6 +370,9 @@ define archhelp echo ' support passing a device tree directly. Replace with the' echo ' nam
Re: [powerpc:next-test] BUILD REGRESSION c827c932c00ccd231a73da9816a51ce2c2b557d6
kernel test robot writes: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test > branch HEAD: c827c932c00ccd231a73da9816a51ce2c2b557d6 powerpc: Use > of_address_to_resource() > > Error/Warning reports: > > https://lore.kernel.org/oe-kbuild-all/202303240411.tq2tzkig-...@intel.com > > Error/Warning: (recently discovered and may have been fixed) > > arch/powerpc/platforms/embedded6xx/ls_uart.c:128:15: error: implicit > declaration of function 'of_address_to_resource' > [-Werror=implicit-function-declaration] > > Error/Warning ids grouped by kconfigs: > > gcc_recent_errors > `-- powerpc-linkstation_defconfig > `-- > arch-powerpc-platforms-embedded6xx-ls_uart.c:error:implicit-declaration-of-function-of_address_to_resource I've dropped that patch for now. cheers
Re: [PATCH v3 4/4] of: address: Always use dma_default_coherent for default coherency
Jiaxun Yang writes: > As for now all arches have dma_default_coherent reflecting default > DMA coherency for of devices, so there is no need to have a standalone > config option. > > Signed-off-by: Jiaxun Yang > --- > v3: Squash setting ARCH_DMA_DEFAULT_COHERENT into this patch. > --- > arch/powerpc/Kconfig | 2 +- > arch/riscv/Kconfig | 2 +- > drivers/of/Kconfig | 4 > drivers/of/address.c | 10 +- > 4 files changed, 3 insertions(+), 15 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 57f5d2f53d06..824e00a1277b 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -113,6 +113,7 @@ config PPC > # > select ARCH_32BIT_OFF_T if PPC32 > select ARCH_DISABLE_KASAN_INLINEif PPC_RADIX_MMU > + select ARCH_DMA_DEFAULT_COHERENTif !NOT_COHERENT_CACHE > select ARCH_ENABLE_MEMORY_HOTPLUG > select ARCH_ENABLE_MEMORY_HOTREMOVE > select ARCH_HAS_COPY_MC if PPC64 > @@ -273,7 +274,6 @@ config PPC > select NEED_PER_CPU_PAGE_FIRST_CHUNKif PPC64 > select NEED_SG_DMA_LENGTH > select OF > - select OF_DMA_DEFAULT_COHERENT if !NOT_COHERENT_CACHE > select OF_EARLY_FLATTREE > select OLD_SIGACTIONif PPC32 > select OLD_SIGSUSPEND Acked-by: Michael Ellerman (powerpc) cheers
Re: Memory coherency issue with IO thread offloading?
Jens Axboe writes: >>> Can the queueing cause the creation of an IO thread (if one does not >>> exist, or all blocked?) >> >> Yep >> >> Since writing this email, I've gone through a lot of different tests. >> Here's a rough listing of what I found: >> >> - Like using the hack patch, if I just limit the number of IO thread >> workers to 1, it seems to pass. At least longer than before, does 1000 >> iterations. >> >> - If I pin each IO worker to a single CPU, it also passes. >> >> - If I liberally sprinkle smp_mb() for the io-wq side, test still fails. >> I've added one before queueing the work item, and after. One before >> the io-wq worker grabs a work item and one after. Eg full hammer >> approach. This still fails. >> >> Puzzling... For the "pin each IO worker to a single CPU" I added some >> basic code around trying to ensure that a work item queued on CPU X >> would be processed by a worker on CPU X, and too a large degree, this >> does happen. But since the work list is a normal list, it's quite >> possible that some other worker finishes its work on CPU Y just in time >> to grab the one from cpu X. I checked and this does happen in the test >> case, yet it still passes. This may be because I got a bit lucky, but >> seems suspect with thousands of passes of the test case. >> >> Another theory there is that it's perhaps related to an io-wq worker >> being rescheduled on a different CPU. Though again puzzled as to why the >> smp_mb sprinkling didn't fix that then. I'm going to try and run the >> test case with JUST the io-wq worker pinning and not caring about where >> the work is processed to see if that does anything. > > Just pinning each worker to whatever CPU they got created on seemingly > fixes the issue too. This does not mean that each worker will process > work on the CPU on which it was queued, just that each worker will > remain on whatever CPU it originally got created on. > > Puzzling... > > Note that it is indeed quite possible that this isn't a ppc issue at > all, just shows on ppc. It could be page cache related, or it could even > be a bug in mariadb itself. I tried binary patching every lwsync to hwsync (read/write to full barrier) in mariadbd and all the libaries it links. It didn't fix the problem. I also tried switching all the kernel barriers/spin locks to using a hwsync, but that also didn't fix it. It's still possible there's somewhere that currently has no barrier at all that needs one, the above would only fix the problem if we have a read/write barrier that actually needs to be a full barrier. I also looked at making all TLB invalidates broadcast, regardless of whether we think the thread has only been on a single CPU. That didn't help, but I'm not sure I got all places where we do TLB invalidates, so I'll look at that some more tomorrow. cheers
Re: Memory coherency issue with IO thread offloading?
Daniel Black writes: > Thanks Jens, Nick, Christophe and Michael for your work so far. > > Apologies for the out of thread email. > > Confirming MariabD-10.6+ is required( when we added liburing), and > previous versions used libaio (which tested without incident as mpe > retested). Thanks! I was trying to follow the threads from the mariadb/server github to find the CI but didn't have much luck. No .travis.yml these days :) > We were (we're now back on the old good kernel Jens indicated) getting > failures like https://buildbot.mariadb.org/#/builders/231/builds/16857 > in a container (of various distro userspaces) on bare metal. > > bare metal end of /proc/cpuinfo > > processor: 127 > cpu: POWER9, altivec supported > clock: 3283.00MHz > revision: 2.2 (pvr 004e 1202) > > timebase: 51200 > platform: PowerNV > model: 9006-22P > machine: PowerNV 9006-22P > firmware: OPAL > MMU: Radix Thanks, looks like that's a Boston, which at least has the same CPU as the machine I'm testing on. I have also reproduced it on bare metal now, but it seems much easier to hit it in an LPAR (on P10). Not sure that's an actual data point, could just be due to other activity on the box. cheers
Re: [PATCH] arch/powerpc/kvm: kvmppc_core_vcpu_create_hv: check for kzalloc failure
Kautuk Consul writes:
> On 2023-03-28 15:44:02, Kautuk Consul wrote:
>> On 2023-03-28 20:44:48, Michael Ellerman wrote:
>> > Kautuk Consul writes:
>> > > kvmppc_vcore_create() might not be able to allocate memory through
>> > > kzalloc. In that case the kvm->arch.online_vcores shouldn't be
>> > > incremented.
>> >
>> > I agree that looks wrong.
>> >
>> > Have you tried to test what goes wrong if it fails? It looks like it
>> > will break the LPCR update, which likely will cause the guest to crash
>> > horribly.
> Also, are you referring to the code in kvmppc_update_lpcr()?
> That code will not crash as it checks for the vc before trying to
> dereference it.
Yeah that's what I was looking at. I didn't mean it would crash, but
that it would bail out early when it sees a NULL vcore, leaving other
vcores with the wrong LPCR value.
But as you say it doesn't happen because qemu quits on the first ENOMEM.
And regardless if qemu does something that means the guest is broken
that's just a qemu bug, no big deal as far as the kernel is concerned.
> But the following 2 places that utilize the arch.online_vcores will have
> problems in logic if the usermode test-case doesn't pull down the
> kvm context after the -ENOMEM vcpu allocation failure:
> book3s_hv.c:3030: if (!kvm->arch.online_vcores) {
> book3s_hv_rm_mmu.c:44: if (kvm->arch.online_vcores == 1 &&
> local_paca->kvm_hstate.kvm_vcpu)
OK. Both of those look harmless to the host.
If we find a case where a misbehaving qemu can crash the host then we
need to be a bit more careful and treat it at least as a
denial-of-service bug. But looks like this is not one of those.
cheers
Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs
"Nicholas Piggin" writes: > On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote: ... >> >> Now that thread.regs doesn't change anymore at each interrupt, it would >> probably be worth dropping it and falling back to task_pt_regs() as >> defined on most architecture. >> Knowing whether a thread is a kernel or user thread can for instance be >> known with PF_KTHREAD flag, so no need of thread.regs for that. > > That would be nice if we can define regs that way, I agree. We should > look into doing that. Yeah it's on the long-list of things that need cleaning up. I think there's some complication in working out which sites are OK to use/give-out the value in pt_regs that's potentially a dummy value, vs cases that actually want to check PF_KTHREAD and do something different. But that's just my hunch I haven't looked through all the sites. The thread.regs = NULL for kernel threads goes back to arch/ppc, about 2002 by the looks: https://github.com/mpe/linux-fullhistory/commit/2a8e186c384c0c911f91cd12367658eabdc820d8#diff-939b705cff722ee75595fad30d56bb1175dfdce49a69adb4d5656f354be076c6 There's no change log of course :) Still maybe it doesn't matter why it was originally done that way, if we can do it differently now. cheers
Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs
Jens Axboe writes: > Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which > from my (arguably very short) checking is not commonly done for other > archs. This is fine, except when PF_IO_WORKER's have been created and > the task does something that causes a coredump to be generated. Do kthread's ever core dump? I didn't think they did, but I can't find any logic to prevent it. Maybe it's always been possible but just never happened due to luck. As Nick said we should probably have a non-NULL regs for PF_IO_WORKERS, but I'll still take this as a nice backportable fix for the immediate crash. I tagged it as Fixes: pointing back at the commit that added ppr_get(), even though I don't know for sure the bug was triggerable back then (v4.8). cheers
Re: [PATCH] arch/powerpc/kvm: kvmppc_core_vcpu_create_hv: check for kzalloc failure
Kautuk Consul writes:
> kvmppc_vcore_create() might not be able to allocate memory through
> kzalloc. In that case the kvm->arch.online_vcores shouldn't be
> incremented.
I agree that looks wrong.
Have you tried to test what goes wrong if it fails? It looks like it
will break the LPCR update, which likely will cause the guest to crash
horribly.
You could use CONFIG_FAIL_SLAB and fail-nth etc. to fail just one
allocation for a guest. Or probably easier to just hack the code to fail
the 4th time it's called using a static counter.
Doesn't really matter but could be interesting.
> Add a check for kzalloc failure and return with -ENOMEM from
> kvmppc_core_vcpu_create_hv().
>
> Signed-off-by: Kautuk Consul
> ---
> arch/powerpc/kvm/book3s_hv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 6ba68dd6190b..e29ee755c920 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -2968,13 +2968,17 @@ static int kvmppc_core_vcpu_create_hv(struct kvm_vcpu
> *vcpu)
> pr_devel("KVM: collision on id %u", id);
> vcore = NULL;
> } else if (!vcore) {
> + vcore = kvmppc_vcore_create(kvm,
> + id & ~(kvm->arch.smt_mode - 1));
That line doesn't need to be wrapped, we allow 90 columns.
> + if (unlikely(!vcore)) {
> + mutex_unlock(>lock);
> + return -ENOMEM;
> + }
Rather than introducing a new return point here, I think it would be
preferable to use the existing !vcore case below.
> /*
>* Take mmu_setup_lock for mutual exclusion
>* with kvmppc_update_lpcr().
>*/
> - err = -ENOMEM;
> - vcore = kvmppc_vcore_create(kvm,
> - id & ~(kvm->arch.smt_mode - 1));
So leave that as is (maybe move the comment down).
And wrap the below in:
+ if (vcore) {
> mutex_lock(>arch.mmu_setup_lock);
> kvm->arch.vcores[core] = vcore;
> kvm->arch.online_vcores++;
mutex_unlock(>arch.mmu_setup_lock);
+ }
}
}
Meaning the vcore == NULL case will fall through to here and return via
this existing path:
mutex_unlock(>lock);
if (!vcore)
return err;
cheers
Re: [PATCH 0/2] KVM: PPC: support kvm selftests
"Nicholas Piggin" writes: > On Tue Mar 28, 2023 at 3:43 AM AEST, Sean Christopherson wrote: >> On Mon, Mar 27, 2023, Nicholas Piggin wrote: >> > On Thu Mar 23, 2023 at 3:41 AM AEST, Sean Christopherson wrote: ... >> > > >> > > What is the long term plan for KVM PPC maintenance? I was under the >> > > impression >> > > that KVM PPC was trending toward "bug fixes only", but the addition of >> > > selftests >> > > support suggests otherwise. ... > >> and ideally there would be one or more M: (and R:) entries as well. I'm not >> all that concerned about the selftests support being abandoned, but the lack >> of >> specific contacts makes it look like KVM PPC is in maintenance-only mode, >> and it >> sounds like that's not the case. > > Yeah, I guess the intention was to bring it a bit more under general > arch/powerpc maintainership but it does look a bit odd having a top > level entry and no contacts. We'll reconsider what to do with that. Yeah I agree it ends up looking a bit weird. The intention was just to make it clear that Paul's tree was no longer where patches were being handled, and that they'd be handled as regular powerpc patches. At the time I hoped we'd relatively quickly be able to add someone as at least a KVM "R:"eviewer, but circumstances intervened. Hopefully we can fix that soon. cheers
Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs
"Nicholas Piggin" writes: > On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote: >> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which >> from my (arguably very short) checking is not commonly done for other >> archs. This is fine, except when PF_IO_WORKER's have been created and >> the task does something that causes a coredump to be generated. Then we >> get this crash: > > Hey Jens, > > Thanks for the testing and the patch. > > I think your patch would work, but I'd be inclined to give the IO worker > a pt_regs so it looks more like other archs and a regular user thread. > > Your IO worker bug reminded me to resurrect some copy_thread patches I > had and I think they should do that > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2023-March/256271.html > > I wouldn't ask you to test it until I've at least tried, do you have a > test case that triggers this? I hit it once on one machine while running the mtr test from the other thread. I'm not sure what leads to it failing that way rather than the usual case of the mariadb test just printing an error. I've got your series applied and am testing it now. cheers
Re: Memory coherency issue with IO thread offloading?
Jens Axboe writes: > On 3/24/23 6:42?PM, Michael Ellerman wrote: >> Jens Axboe writes: >>> I got a report sent to me from mariadb, in where 5.10.158 works fine and >>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test >>> case. Beware that this email is long, as I'm trying to include >>> everything that may be relevant... >>> >>> The test case in question is pretty simple. On debian testing, do: >>> >>> $ sudo apt-get install mariadb-test >>> $ cd /usr/share/mysql/mysql-test >>> $ ./mtr --mysqld=--innodb-flush-method=fsync >>> --mysqld=--innodb-use-native-aio=1 --vardir=/dev/shm/mysql --force >>> encryption.innodb_encryption,innodb,undo0 --repeat=200 >> >> I mostly use Fedora, the package name is the same but the mtr binary >> ends up in /usr/share/mysql. >> >>> and if it fails, you'll see something like: >>> >>> encryption.innodb_encryption 'innodb,undo0' [ 6 pass ] 3120 >>> encryption.innodb_encryption 'innodb,undo0' [ 7 pass ] 3123 >>> encryption.innodb_encryption 'innodb,undo0' [ 8 pass ] 3042 >>> encryption.innodb_encryption 'innodb,undo0' [ 9 fail ] >>> Test ended at 2023-03-23 16:55:17 >> >> I haven't been able to get this to fail yet. I've done several runs with >> --repeat=500 and haven't seen any errors yet. >> >> Are there any CONFIG options I'd need to trip this? > > I don't think you need any special CONFIG options. I'll attach my config > here, and I know the default distro one hits it too. But perhaps the > mariadb version is not new enough? I think you need 10.6 or above, as > will use io_uring by default. What version are you running? Yeah I had 10.5. I ended up building mariadb git, and now I have it reproducing on one VM I have. For some reason I can't reproduce with the same setup on a bare metal machine, which is odd. ... >> My first guess would be that there's some missing barriers between the >> thread that queues the IO and the IO worker thread. > > That was my guess too, and I consulted Paul McKenney as well on that. > And he had some ideas of course, in terms of ordering of the CQ ring. > But tried it all out, and it still failed in the same way... > >> I think you're using schedule_work() for that though, which should be a >> full barrier. Could it be on the completion side? > > queue_work() for the patch, before that it's io-wq which is an internal > IO thread worker pool. The latter just needs a spin_lock() around > queueing the work, and then a wake of the task. Typing this out, maybe > this is where a barrier is now missing? If the IO thread is already > running rather than sleeping? It sounded promising, but I've tried adding barriers around all the spin locks and it hasn't made any difference. Are there barriers in the userspace code also? If so would they be in liburing or in the actual mariadb code? Possibly I'm completely wrong about barriers and it's something else, but I can't think what. I checked that the liburing tests are passing. Any idea what mariadb is doing different that's likely to be triggering the bug? cheers
Re: Memory coherency issue with IO thread offloading?
Jens Axboe writes: > Hi, Hi Jens, Thanks for the report. > I got a report sent to me from mariadb, in where 5.10.158 works fine and > 5.10.162 is broken. And in fact, current 6.3-rc also fails the test > case. Beware that this email is long, as I'm trying to include > everything that may be relevant... > > The test case in question is pretty simple. On debian testing, do: > > $ sudo apt-get install mariadb-test > $ cd /usr/share/mysql/mysql-test > $ ./mtr --mysqld=--innodb-flush-method=fsync > --mysqld=--innodb-use-native-aio=1 --vardir=/dev/shm/mysql --force > encryption.innodb_encryption,innodb,undo0 --repeat=200 I mostly use Fedora, the package name is the same but the mtr binary ends up in /usr/share/mysql. > and if it fails, you'll see something like: > > encryption.innodb_encryption 'innodb,undo0' [ 6 pass ] 3120 > encryption.innodb_encryption 'innodb,undo0' [ 7 pass ] 3123 > encryption.innodb_encryption 'innodb,undo0' [ 8 pass ] 3042 > encryption.innodb_encryption 'innodb,undo0' [ 9 fail ] > Test ended at 2023-03-23 16:55:17 I haven't been able to get this to fail yet. I've done several runs with --repeat=500 and haven't seen any errors yet. Are there any CONFIG options I'd need to trip this? ... > Today I finally gave up and ran a basic experiment, which simply > offloads the writes to a kthread. Since powerpc has an interesting > memory coherency model, my suspicion was that the work involved with > switching MMs for the kthread could just be the main difference here. > The patch is really dumb and simple - rather than queue the write to an > IO thread, it just offloads it to a kthread that then does > kthread_use_mm(), perform write with the same write handler, > kthread_unuse_mm(). AND THIS WORKS! Usually the above mtr test would > fail in 2..20 loops, I've now done 200 and 500 loops and it's fine. Can you share the patch that does that? It would help me track down where exactly in the io_uring code you're talking about. > Which then leads me to the question, what about the IO thread offload > makes this fail on powerpc (and no other arch I've tested on, including > x86/x86-64/aarch64/hppa64)? The offload should be equivalent to having a > thread in userspace in the application, and having that thread just > perform the writes. Is there some magic involved with the kthread mm > use/unuse that makes this sufficiently consistent on powerpc? I've tried > any mix of isync()/mb and making the flush_dcache_page() unconditionally > done in the filemap read/write helpers, and it still falls flat on its > face with the offload to an IO thread. My first guess would be that there's some missing barriers between the thread that queues the IO and the IO worker thread. I think you're using schedule_work() for that though, which should be a full barrier. Could it be on the completion side? I can't think of any magic in kthread_use_mm() other than extra barriers. In particular kthread_unuse_mm() has an smp_mb__after_spinlock() which is a full memory barrier on powerpc but is a nop on some other architectures, x86 at least. > I must clearly be missing something here, which is why I'm emailing the > powerpc Gods for help :-) Unfortunately the true God of powerpc memory ordering has left us and ascended into the Metaverse ;) cheers
Re: Memory coherency issue with IO thread offloading?
Jens Axboe writes: > On 3/24/23 1:27?AM, Christophe Leroy wrote: >> Le 23/03/2023 ? 19:54, Jens Axboe a ?crit : >>> I got a report sent to me from mariadb, in where 5.10.158 works fine and >>> 5.10.162 is broken. And in fact, current 6.3-rc also fails the test >>> case. Beware that this email is long, as I'm trying to include >>> everything that may be relevant... >> >> Which variant of powerpc ? 32 or 64 bits ? Book3S or BookE ? > > I knew I'd forget something important... It's power9: > > processor : 0 > cpu : POWER9 (architected), altivec supported > clock : 2200.00MHz > revision : 2.2 (pvr 004e 1202) Believe it or not there's still more variables in play, Power9 has two different MMUs, and Linux can run on two different hypervisors as well as on bare metal P9 :) Can you paste the last ~10 lines of /proc/cpuinfo, with the "machine", "firmware" and "MMU" lines, that should tell us everything we need to know. cheers
