* [PATCH] powerpc/64s: accumulate_stolen_time remove irq mask workaround
From: Nicholas Piggin @ 2021-06-23 2:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
The caller has been moved to C after irq soft-mask state has been
reconciled, and Linux irqs have been marked as disabled, so this
does not have to play games with irq internals.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/time.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b67d93a609a2..d0308e804063 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -231,24 +231,13 @@ static u64 scan_dispatch_log(u64 stop_tb)
void notrace accumulate_stolen_time(void)
{
u64 sst, ust;
- unsigned long save_irq_soft_mask = irq_soft_mask_return();
struct cpu_accounting_data *acct = &local_paca->accounting;
- /* We are called early in the exception entry, before
- * soft/hard_enabled are sync'ed to the expected state
- * for the exception. We are hard disabled but the PACA
- * needs to reflect that so various debug stuff doesn't
- * complain
- */
- irq_soft_mask_set(IRQS_DISABLED);
-
sst = scan_dispatch_log(acct->starttime_user);
ust = scan_dispatch_log(acct->starttime);
acct->stime -= sst;
acct->utime -= ust;
acct->steal_time += ust + sst;
-
- irq_soft_mask_set(save_irq_soft_mask);
}
static inline u64 calculate_stolen_time(u64 stop_tb)
--
2.23.0
^ permalink raw reply related
* [PATCH v2] powerpc: add compile-time support for lbarx, lharx
From: Nicholas Piggin @ 2021-06-23 3:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
ISA v2.06 (POWER7 and up) as well as e6500 support lbarx and lharx.
Add a compile option that allows code to use it, and add support in
cmpxchg and xchg 8 and 16 bit values without shifting and masking.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
v2: Fixed lwarx->lharx typo, switched to PPC_HAS_
arch/powerpc/Kconfig | 3 +
arch/powerpc/include/asm/cmpxchg.h | 236 ++++++++++++++++++++++++-
arch/powerpc/lib/sstep.c | 21 +--
arch/powerpc/platforms/Kconfig.cputype | 5 +
4 files changed, 254 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 088dd2afcfe4..dc17f4d51a79 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -278,6 +278,9 @@ config PPC_BARRIER_NOSPEC
default y
depends on PPC_BOOK3S_64 || PPC_FSL_BOOK3E
+config PPC_HAS_LBARX_LHARX
+ bool
+
config EARLY_PRINTK
bool
default y
diff --git a/arch/powerpc/include/asm/cmpxchg.h b/arch/powerpc/include/asm/cmpxchg.h
index cf091c4c22e5..28fbd57db1ec 100644
--- a/arch/powerpc/include/asm/cmpxchg.h
+++ b/arch/powerpc/include/asm/cmpxchg.h
@@ -77,10 +77,76 @@ u32 __cmpxchg_##type##sfx(volatile void *p, u32 old, u32 new) \
* the previous value stored there.
*/
+#ifndef CONFIG_PPC_HAS_LBARX_LHARX
XCHG_GEN(u8, _local, "memory");
XCHG_GEN(u8, _relaxed, "cc");
XCHG_GEN(u16, _local, "memory");
XCHG_GEN(u16, _relaxed, "cc");
+#else
+static __always_inline unsigned long
+__xchg_u8_local(volatile void *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1: lbarx %0,0,%2 \n"
+" stbcx. %3,0,%2 \n\
+ bne- 1b"
+ : "=&r" (prev), "+m" (*(volatile unsigned char *)p)
+ : "r" (p), "r" (val)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__xchg_u8_relaxed(u8 *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1: lbarx %0,0,%2\n"
+" stbcx. %3,0,%2\n"
+" bne- 1b"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (val)
+ : "cc");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__xchg_u16_local(volatile void *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1: lharx %0,0,%2 \n"
+" sthcx. %3,0,%2 \n\
+ bne- 1b"
+ : "=&r" (prev), "+m" (*(volatile unsigned short *)p)
+ : "r" (p), "r" (val)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__xchg_u16_relaxed(u16 *p, unsigned long val)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__(
+"1: lharx %0,0,%2\n"
+" sthcx. %3,0,%2\n"
+" bne- 1b"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (val)
+ : "cc");
+
+ return prev;
+}
+#endif
static __always_inline unsigned long
__xchg_u32_local(volatile void *p, unsigned long val)
@@ -198,11 +264,12 @@ __xchg_relaxed(void *ptr, unsigned long x, unsigned int size)
(__typeof__(*(ptr))) __xchg_relaxed((ptr), \
(unsigned long)_x_, sizeof(*(ptr))); \
})
+
/*
* Compare and exchange - if *p == old, set it to new,
* and return the old value of *p.
*/
-
+#ifndef CONFIG_PPC_HAS_LBARX_LHARX
CMPXCHG_GEN(u8, , PPC_ATOMIC_ENTRY_BARRIER, PPC_ATOMIC_EXIT_BARRIER, "memory");
CMPXCHG_GEN(u8, _local, , , "memory");
CMPXCHG_GEN(u8, _acquire, , PPC_ACQUIRE_BARRIER, "memory");
@@ -211,6 +278,173 @@ CMPXCHG_GEN(u16, , PPC_ATOMIC_ENTRY_BARRIER, PPC_ATOMIC_EXIT_BARRIER, "memory");
CMPXCHG_GEN(u16, _local, , , "memory");
CMPXCHG_GEN(u16, _acquire, , PPC_ACQUIRE_BARRIER, "memory");
CMPXCHG_GEN(u16, _relaxed, , , "cc");
+#else
+static __always_inline unsigned long
+__cmpxchg_u8(volatile unsigned char *p, unsigned long old, unsigned long new)
+{
+ unsigned int prev;
+
+ __asm__ __volatile__ (
+ PPC_ATOMIC_ENTRY_BARRIER
+"1: lbarx %0,0,%2 # __cmpxchg_u8\n\
+ cmpw 0,%0,%3\n\
+ bne- 2f\n"
+" stbcx. %4,0,%2\n\
+ bne- 1b"
+ PPC_ATOMIC_EXIT_BARRIER
+ "\n\
+2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u8_local(volatile unsigned char *p, unsigned long old,
+ unsigned long new)
+{
+ unsigned int prev;
+
+ __asm__ __volatile__ (
+"1: lbarx %0,0,%2 # __cmpxchg_u8\n\
+ cmpw 0,%0,%3\n\
+ bne- 2f\n"
+" stbcx. %4,0,%2\n\
+ bne- 1b"
+ "\n\
+2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u8_relaxed(u8 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1: lbarx %0,0,%2 # __cmpxchg_u8_relaxed\n"
+" cmpw 0,%0,%3\n"
+" bne- 2f\n"
+" stbcx. %4,0,%2\n"
+" bne- 1b\n"
+"2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u8_acquire(u8 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1: lbarx %0,0,%2 # __cmpxchg_u8_acquire\n"
+" cmpw 0,%0,%3\n"
+" bne- 2f\n"
+" stbcx. %4,0,%2\n"
+" bne- 1b\n"
+ PPC_ACQUIRE_BARRIER
+ "\n"
+"2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u16(volatile unsigned short *p, unsigned long old, unsigned long new)
+{
+ unsigned int prev;
+
+ __asm__ __volatile__ (
+ PPC_ATOMIC_ENTRY_BARRIER
+"1: lharx %0,0,%2 # __cmpxchg_u16\n\
+ cmpw 0,%0,%3\n\
+ bne- 2f\n"
+" sthcx. %4,0,%2\n\
+ bne- 1b"
+ PPC_ATOMIC_EXIT_BARRIER
+ "\n\
+2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u16_local(volatile unsigned short *p, unsigned long old,
+ unsigned long new)
+{
+ unsigned int prev;
+
+ __asm__ __volatile__ (
+"1: lharx %0,0,%2 # __cmpxchg_u16\n\
+ cmpw 0,%0,%3\n\
+ bne- 2f\n"
+" sthcx. %4,0,%2\n\
+ bne- 1b"
+ "\n\
+2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u16_relaxed(u16 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1: lharx %0,0,%2 # __cmpxchg_u16_relaxed\n"
+" cmpw 0,%0,%3\n"
+" bne- 2f\n"
+" sthcx. %4,0,%2\n"
+" bne- 1b\n"
+"2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc");
+
+ return prev;
+}
+
+static __always_inline unsigned long
+__cmpxchg_u16_acquire(u16 *p, unsigned long old, unsigned long new)
+{
+ unsigned long prev;
+
+ __asm__ __volatile__ (
+"1: lharx %0,0,%2 # __cmpxchg_u16_acquire\n"
+" cmpw 0,%0,%3\n"
+" bne- 2f\n"
+" sthcx. %4,0,%2\n"
+" bne- 1b\n"
+ PPC_ACQUIRE_BARRIER
+ "\n"
+"2:"
+ : "=&r" (prev), "+m" (*p)
+ : "r" (p), "r" (old), "r" (new)
+ : "cc", "memory");
+
+ return prev;
+}
+#endif
static __always_inline unsigned long
__cmpxchg_u32(volatile unsigned int *p, unsigned long old, unsigned long new)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index f998e655b570..3a03c8ce1e95 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -131,6 +131,7 @@ config GENERIC_CPU
bool "Generic (POWER8 and above)"
depends on PPC64 && CPU_LITTLE_ENDIAN
select ARCH_HAS_FAST_MULTIPLIER
+ select PPC_HAS_LBARX_LHARX
config GENERIC_CPU
bool "Generic 32 bits powerpc"
@@ -152,16 +153,19 @@ config POWER7_CPU
bool "POWER7"
depends on PPC_BOOK3S_64
select ARCH_HAS_FAST_MULTIPLIER
+ select PPC_HAS_LBARX_LHARX
config POWER8_CPU
bool "POWER8"
depends on PPC_BOOK3S_64
select ARCH_HAS_FAST_MULTIPLIER
+ select PPC_HAS_LBARX_LHARX
config POWER9_CPU
bool "POWER9"
depends on PPC_BOOK3S_64
select ARCH_HAS_FAST_MULTIPLIER
+ select PPC_HAS_LBARX_LHARX
config E5500_CPU
bool "Freescale e5500"
@@ -170,6 +174,7 @@ config E5500_CPU
config E6500_CPU
bool "Freescale e6500"
depends on E500
+ select PPC_HAS_LBARX_LHARX
config 860_CPU
bool "8xx family"
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc: Make PPC_IRQ_SOFT_MASK_DEBUG depend on PPC64
From: Nicholas Piggin @ 2021-06-23 3:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
32-bit platforms don't have irq soft masking.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 6342f9da4545..45d871fb9155 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -84,6 +84,7 @@ config MSI_BITMAP_SELFTEST
config PPC_IRQ_SOFT_MASK_DEBUG
bool "Include extra checks for powerpc irq soft masking"
+ depends on PPC64
config XMON
bool "Include xmon kernel debugger"
--
2.23.0
^ permalink raw reply related
* [powerpc:next-test] BUILD REGRESSION a23408e2575e49c4394f8733c78dce907286ac8e
From: kernel test robot @ 2021-06-23 3:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: a23408e2575e49c4394f8733c78dce907286ac8e powerpc/64s/interrupt: Check and fix srr_valid without crashing
possible Error/Warning in current branch:
arch/powerpc/platforms/52xx/mpc52xx_pm.c:58:5: error: stack frame size (1040) exceeds limit (1024) in function 'mpc52xx_pm_prepare' [-Werror,-Wframe-larger-than]
arch/powerpc/platforms/52xx/mpc52xx_pm.c:58:5: error: stack frame size of 1040 bytes in function 'mpc52xx_pm_prepare' [-Werror,-Wframe-larger-than]
arch/powerpc/sysdev/ehv_pic.c:111:5: error: no previous prototype for function 'ehv_pic_set_irq_type' [-Werror,-Wmissing-prototypes]
Error/Warning ids grouped by kconfigs:
clang_recent_errors
|-- powerpc-randconfig-r005-20210622
| |-- arch-powerpc-platforms-52xx-mpc52xx_pm.c:error:stack-frame-size-()-exceeds-limit-()-in-function-mpc52xx_pm_prepare-Werror-Wframe-larger-than
| `-- arch-powerpc-platforms-52xx-mpc52xx_pm.c:error:stack-frame-size-of-bytes-in-function-mpc52xx_pm_prepare-Werror-Wframe-larger-than
`-- powerpc-randconfig-r035-20210622
`-- arch-powerpc-sysdev-ehv_pic.c:error:no-previous-prototype-for-function-ehv_pic_set_irq_type-Werror-Wmissing-prototypes
elapsed time: 725m
configs tested: 107
configs skipped: 2
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm h3600_defconfig
powerpc klondike_defconfig
arm imx_v6_v7_defconfig
powerpc arches_defconfig
arm rpc_defconfig
powerpc motionpro_defconfig
arc vdk_hs38_defconfig
powerpc powernv_defconfig
powerpc mpc832x_rdb_defconfig
powerpc tqm5200_defconfig
powerpc gamecube_defconfig
h8300 edosk2674_defconfig
sh se7724_defconfig
mips malta_defconfig
arc tb10x_defconfig
mips ip28_defconfig
arm eseries_pxa_defconfig
powerpc ep8248e_defconfig
sh rts7751r2dplus_defconfig
mips rbtx49xx_defconfig
sh se7343_defconfig
powerpc mpc836x_rdk_defconfig
sh kfr2r09-romimage_defconfig
m68k atari_defconfig
powerpc tqm8555_defconfig
powerpc mpc8315_rdb_defconfig
powerpc sam440ep_defconfig
powerpc sequoia_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
arc allyesconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210622
i386 randconfig-a002-20210622
i386 randconfig-a003-20210622
i386 randconfig-a006-20210622
i386 randconfig-a005-20210622
i386 randconfig-a004-20210622
x86_64 randconfig-a012-20210622
x86_64 randconfig-a016-20210622
x86_64 randconfig-a015-20210622
x86_64 randconfig-a014-20210622
x86_64 randconfig-a013-20210622
x86_64 randconfig-a011-20210622
i386 randconfig-a014-20210622
i386 randconfig-a013-20210622
i386 randconfig-a015-20210622
i386 randconfig-a012-20210622
i386 randconfig-a016-20210622
i386 randconfig-a011-20210622
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210622
x86_64 randconfig-a002-20210622
x86_64 randconfig-a001-20210622
x86_64 randconfig-a005-20210622
x86_64 randconfig-a003-20210622
x86_64 randconfig-a004-20210622
x86_64 randconfig-a006-20210622
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next] BUILD SUCCESS a736143afd036f2078fe19435b16fd55abc789a9
From: kernel test robot @ 2021-06-23 3:47 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: a736143afd036f2078fe19435b16fd55abc789a9 Merge branch 'topic/ppc-kvm' into next
elapsed time: 725m
configs tested: 104
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm h3600_defconfig
powerpc klondike_defconfig
arm imx_v6_v7_defconfig
powerpc arches_defconfig
arm rpc_defconfig
nds32 alldefconfig
powerpc maple_defconfig
arm corgi_defconfig
arc vdk_hs38_smp_defconfig
mips sb1250_swarm_defconfig
h8300 edosk2674_defconfig
sh se7724_defconfig
mips malta_defconfig
arc tb10x_defconfig
mips ip28_defconfig
arm eseries_pxa_defconfig
powerpc ep8248e_defconfig
sh rts7751r2dplus_defconfig
mips rbtx49xx_defconfig
sh se7343_defconfig
arm vt8500_v6_v7_defconfig
arm axm55xx_defconfig
arm lpc18xx_defconfig
powerpc tqm8560_defconfig
openrisc simple_smp_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210622
i386 randconfig-a002-20210622
i386 randconfig-a003-20210622
i386 randconfig-a006-20210622
i386 randconfig-a005-20210622
i386 randconfig-a004-20210622
x86_64 randconfig-a012-20210622
x86_64 randconfig-a016-20210622
x86_64 randconfig-a015-20210622
x86_64 randconfig-a014-20210622
x86_64 randconfig-a013-20210622
x86_64 randconfig-a011-20210622
i386 randconfig-a014-20210622
i386 randconfig-a013-20210622
i386 randconfig-a015-20210622
i386 randconfig-a012-20210622
i386 randconfig-a016-20210622
i386 randconfig-a011-20210622
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210622
x86_64 randconfig-a002-20210622
x86_64 randconfig-a001-20210622
x86_64 randconfig-a005-20210622
x86_64 randconfig-a003-20210622
x86_64 randconfig-a004-20210622
x86_64 randconfig-a006-20210622
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] powerpc: offline CPU in stop_this_cpu
From: Nicholas Piggin @ 2021-06-23 4:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nicholas Piggin
printk_safe_flush_on_panic() has special lock breaking code for the
case where we panic()ed with the console lock held. It relies on
panic IPI causing other CPUs to mark themselves offline.
Do as most other architectures do.
This effectively reverts commit de6e5d38417e ("powerpc: smp_send_stop do
not offline stopped CPUs"), unfortunately it may result in some false
positive warnings, but the alternative is more situations where we can
crash without getting messages out.
Fixes: de6e5d38417e ("powerpc: smp_send_stop do not offline stopped CPUs")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/smp.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 2e05c783440a..bf12cca86d70 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -619,6 +619,8 @@ static void nmi_stop_this_cpu(struct pt_regs *regs)
/*
* IRQs are already hard disabled by the smp_handle_nmi_ipi.
*/
+ set_cpu_online(smp_processor_id(), false);
+
spin_begin();
while (1)
spin_cpu_relax();
@@ -634,6 +636,15 @@ void smp_send_stop(void)
static void stop_this_cpu(void *dummy)
{
hard_irq_disable();
+
+ /*
+ * Offlining CPUs in stop_this_cpu can result in scheduler warnings,
+ * (see commit de6e5d38417e), but printk_safe_flush_on_panic() wants
+ * to know other CPUs are offline before it breaks locks to flush
+ * printk buffers, in case we panic()ed while holding the lock.
+ */
+ set_cpu_online(smp_processor_id(), false);
+
spin_begin();
while (1)
spin_cpu_relax();
--
2.23.0
^ permalink raw reply related
* [PATCH V4 0/4] cpufreq: Migrate away from ->stop_cpu() callback
From: Viresh Kumar @ 2021-06-23 4:24 UTC (permalink / raw)
To: Rafael Wysocki, Alex Shi, Benjamin Herrenschmidt, Jonathan Corbet,
Len Brown, Michael Ellerman, Paul Mackerras, Srinivas Pandruvada,
Viresh Kumar
Cc: Vincent Guittot, linux-doc, linux-pm, linux-kernel,
Dirk Brandewie, linuxppc-dev
Hi Rafael,
These are based on your patch [1] now.
commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered notifier for different events like CPU_DOWN_PREPARE and
CPU_POST_DEAD. The stop_cpu() callback was called during the
CPU_DOWN_PREPARE event.
This is no longer the case, cpuhp_cpufreq_offline() is called only once
by the CPU hotplug core now and we don't really need two separate
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the offline() or exit() callback instead of stop_cpu().
V3->V4:
- Based on a cleanup patch [1] from Rafael, apart from 5.13-rc7.
- No need to update exit() for intel pstate anymore.
- Remove the stop_cpu() callback completely.
--
Viresh
[1] https://lore.kernel.org/linux-pm/5490292.DvuYhMxLoT@kreacher/
Viresh Kumar (4):
cpufreq: cppc: Migrate to ->exit() callback instead of ->stop_cpu()
cpufreq: intel_pstate: Migrate to ->offline() instead of ->stop_cpu()
cpufreq: powerenv: Migrate to ->exit() callback instead of
->stop_cpu()
cpufreq: Remove stop_cpu() callback
Documentation/cpu-freq/cpu-drivers.rst | 3 --
.../zh_CN/cpu-freq/cpu-drivers.rst | 3 --
drivers/cpufreq/cppc_cpufreq.c | 46 ++++++++++---------
drivers/cpufreq/cpufreq.c | 3 --
drivers/cpufreq/intel_pstate.c | 10 +---
drivers/cpufreq/powernv-cpufreq.c | 23 ++++------
include/linux/cpufreq.h | 1 -
7 files changed, 35 insertions(+), 54 deletions(-)
--
2.31.1.272.g89b43f80a514
^ permalink raw reply
* [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback instead of ->stop_cpu()
From: Viresh Kumar @ 2021-06-23 4:24 UTC (permalink / raw)
To: Rafael Wysocki, Viresh Kumar, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, Vincent Guittot, linux-kernel, linux-pm
In-Reply-To: <cover.1624421816.git.viresh.kumar@linaro.org>
commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered notifier for different events like CPU_DOWN_PREPARE and
CPU_POST_DEAD. The stop_cpu() callback was called during the
CPU_DOWN_PREPARE event.
This is no longer the case, cpuhp_cpufreq_offline() is called only once
by the CPU hotplug core now and we don't really need two separate
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/cpufreq/powernv-cpufreq.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index e439b43c19eb..005600cef273 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -875,7 +875,15 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
- /* timer is deleted in cpufreq_cpu_stop() */
+ struct powernv_smp_call_data freq_data;
+ struct global_pstate_info *gpstates = policy->driver_data;
+
+ freq_data.pstate_id = idx_to_pstate(powernv_pstate_info.min);
+ freq_data.gpstate_id = idx_to_pstate(powernv_pstate_info.min);
+ smp_call_function_single(policy->cpu, set_pstate, &freq_data, 1);
+ if (gpstates)
+ del_timer_sync(&gpstates->timer);
+
kfree(policy->driver_data);
return 0;
@@ -1007,18 +1015,6 @@ static struct notifier_block powernv_cpufreq_opal_nb = {
.priority = 0,
};
-static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)
-{
- struct powernv_smp_call_data freq_data;
- struct global_pstate_info *gpstates = policy->driver_data;
-
- freq_data.pstate_id = idx_to_pstate(powernv_pstate_info.min);
- freq_data.gpstate_id = idx_to_pstate(powernv_pstate_info.min);
- smp_call_function_single(policy->cpu, set_pstate, &freq_data, 1);
- if (gpstates)
- del_timer_sync(&gpstates->timer);
-}
-
static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
unsigned int target_freq)
{
@@ -1042,7 +1038,6 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.target_index = powernv_cpufreq_target_index,
.fast_switch = powernv_fast_switch,
.get = powernv_cpufreq_get,
- .stop_cpu = powernv_cpufreq_stop_cpu,
.attr = powernv_cpu_freq_attr,
};
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related
* [powerpc:topic/ppc-kvm] BUILD SUCCESS 51696f39cbee5bb684e7959c0c98b5f54548aa34
From: kernel test robot @ 2021-06-23 4:40 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm
branch HEAD: 51696f39cbee5bb684e7959c0c98b5f54548aa34 KVM: PPC: Book3S HV: Workaround high stack usage with clang
elapsed time: 777m
configs tested: 97
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm h3600_defconfig
powerpc klondike_defconfig
arm imx_v6_v7_defconfig
powerpc arches_defconfig
arm rpc_defconfig
powerpc sam440ep_defconfig
sh se7705_defconfig
powerpc mpc834x_itxgp_defconfig
mips malta_defconfig
xtensa alldefconfig
powerpc makalu_defconfig
h8300 edosk2674_defconfig
sh se7724_defconfig
arc tb10x_defconfig
mips rbtx49xx_defconfig
sh se7343_defconfig
m68k mvme16x_defconfig
arm realview_defconfig
x86_64 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210622
i386 randconfig-a002-20210622
i386 randconfig-a003-20210622
i386 randconfig-a006-20210622
i386 randconfig-a005-20210622
i386 randconfig-a004-20210622
x86_64 randconfig-a012-20210622
x86_64 randconfig-a016-20210622
x86_64 randconfig-a015-20210622
x86_64 randconfig-a014-20210622
x86_64 randconfig-a013-20210622
x86_64 randconfig-a011-20210622
i386 randconfig-a011-20210622
i386 randconfig-a014-20210622
i386 randconfig-a013-20210622
i386 randconfig-a015-20210622
i386 randconfig-a012-20210622
i386 randconfig-a016-20210622
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 rhel-8.3-kbuiltin
x86_64 kexec
clang tested configs:
x86_64 randconfig-b001-20210622
x86_64 randconfig-a002-20210622
x86_64 randconfig-a001-20210622
x86_64 randconfig-a005-20210622
x86_64 randconfig-a003-20210622
x86_64 randconfig-a004-20210622
x86_64 randconfig-a006-20210622
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] selftests/powerpc: Use req_max_processed_len from sysfs NX capabilities
From: Haren Myneni @ 2021-06-23 5:17 UTC (permalink / raw)
To: linuxppc-dev, mpe, npiggin, rzinsly
On PowerVM, the hypervisor defines the maximum buffer length for
each NX request and the kernel exported this value via sysfs.
This patch reads this value if the sysfs entry is available and
is used to limit the request length.
Signed-off-by: Haren Myneni <haren@linux.ibm.com>
---
.../testing/selftests/powerpc/nx-gzip/Makefile | 4 ++--
.../selftests/powerpc/nx-gzip/gzfht_test.c | 17 +++++++++++++++--
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/powerpc/nx-gzip/Makefile b/tools/testing/selftests/powerpc/nx-gzip/Makefile
index 640fad6cc2c7..0785c2e99d40 100644
--- a/tools/testing/selftests/powerpc/nx-gzip/Makefile
+++ b/tools/testing/selftests/powerpc/nx-gzip/Makefile
@@ -1,8 +1,8 @@
-CFLAGS = -O3 -m64 -I./include
+CFLAGS = -O3 -m64 -I./include -I../include
TEST_GEN_FILES := gzfht_test gunz_test
TEST_PROGS := nx-gzip-test.sh
include ../../lib.mk
-$(TEST_GEN_FILES): gzip_vas.c
+$(TEST_GEN_FILES): gzip_vas.c ../utils.c
diff --git a/tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c b/tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c
index b099753b50e4..095195a25687 100644
--- a/tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c
+++ b/tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c
@@ -60,6 +60,7 @@
#include <assert.h>
#include <errno.h>
#include <signal.h>
+#include "utils.h"
#include "nxu.h"
#include "nx.h"
@@ -70,6 +71,8 @@ FILE *nx_gzip_log;
#define FNAME_MAX 1024
#define FEXT ".nx.gz"
+#define SYSFS_MAX_REQ_BUF_PATH "devices/vio/ibm,compression-v1/nx_gzip_caps/req_max_processed_len"
+
/*
* LZ counts returned in the user supplied nx_gzip_crb_cpb_t structure.
*/
@@ -244,6 +247,7 @@ int compress_file(int argc, char **argv, void *handle)
struct nx_gzip_crb_cpb_t *cmdp;
uint32_t pagelen = 65536;
int fault_tries = NX_MAX_FAULTS;
+ char buf[32];
cmdp = (void *)(uintptr_t)
aligned_alloc(sizeof(struct nx_gzip_crb_cpb_t),
@@ -263,8 +267,17 @@ int compress_file(int argc, char **argv, void *handle)
assert(NULL != (outbuf = (char *)malloc(outlen)));
nxu_touch_pages(outbuf, outlen, pagelen, 1);
- /* Compress piecemeal in smallish chunks */
- chunk = 1<<22;
+ /*
+ * On PowerVM, the hypervisor defines the maximum request buffer
+ * size is defined and this value is available via sysfs.
+ */
+ if (!read_sysfs_file(SYSFS_MAX_REQ_BUF_PATH, buf, sizeof(buf))) {
+ chunk = atoi(buf);
+ } else {
+ /* sysfs entry is not available on PowerNV */
+ /* Compress piecemeal in smallish chunks */
+ chunk = 1<<22;
+ }
/* Write the gzip header to the stream */
num_hdr_bytes = gzip_header_blank(outbuf);
--
2.18.2
^ permalink raw reply related
* [PATCH v2] powerpc/kprobes: Fix Oops by passing ppc_inst as a pointer to emulate_step() on ppc32
From: Christophe Leroy @ 2021-06-23 5:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
From: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Trying to use a kprobe on ppc32 results in the below splat:
BUG: Unable to handle kernel data access on read at 0x7c0802a6
Faulting instruction address: 0xc002e9f0
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PowerPC 44x Platform
Modules linked in:
CPU: 0 PID: 89 Comm: sh Not tainted 5.13.0-rc1-01824-g3a81c0495fdb #7
NIP: c002e9f0 LR: c0011858 CTR: 00008a47
REGS: c292fd50 TRAP: 0300 Not tainted (5.13.0-rc1-01824-g3a81c0495fdb)
MSR: 00009000 <EE,ME> CR: 24002002 XER: 20000000
DEAR: 7c0802a6 ESR: 00000000
<snip>
NIP [c002e9f0] emulate_step+0x28/0x324
LR [c0011858] optinsn_slot+0x128/0x10000
Call Trace:
opt_pre_handler+0x7c/0xb4 (unreliable)
optinsn_slot+0x128/0x10000
ret_from_syscall+0x0/0x28
The offending instruction is:
81 24 00 00 lwz r9,0(r4)
Here, we are trying to load the second argument to emulate_step():
struct ppc_inst, which is the instruction to be emulated. On ppc64,
structures are passed in registers when passed by value. However, per
the ppc32 ABI, structures are always passed to functions as pointers.
This isn't being adhered to when setting up the call to emulate_step()
in the optprobe trampoline. Fix the same.
Fixes: eacf4c0202654a ("powerpc: Enable OPTPROBES on PPC32")
Cc: stable@vger.kernel.org
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
v2: Rebased on powerpc/merge 7f030e9d57b8
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/optprobes.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/optprobes.c b/arch/powerpc/kernel/optprobes.c
index 2b8fe40069ad..53facb4b377f 100644
--- a/arch/powerpc/kernel/optprobes.c
+++ b/arch/powerpc/kernel/optprobes.c
@@ -228,8 +228,12 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op, struct kprobe *p)
/*
* 3. load instruction to be emulated into relevant register, and
*/
- temp = ppc_inst_read(p->ainsn.insn);
- patch_imm_load_insns(ppc_inst_as_ulong(temp), 4, buff + TMPL_INSN_IDX);
+ if (IS_ENABLED(CONFIG_PPC64)) {
+ temp = ppc_inst_read(p->ainsn.insn);
+ patch_imm_load_insns(ppc_inst_as_ulong(temp), 4, buff + TMPL_INSN_IDX);
+ } else {
+ patch_imm_load_insns((unsigned long)p->ainsn.insn, 4, buff + TMPL_INSN_IDX);
+ }
/*
* 4. branch back from trampoline
--
2.25.0
^ permalink raw reply related
* Re: [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback instead of ->stop_cpu()
From: Michael Ellerman @ 2021-06-23 5:45 UTC (permalink / raw)
To: Viresh Kumar, Rafael Wysocki, Viresh Kumar,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, Vincent Guittot, linux-kernel, linux-pm
In-Reply-To: <e40e57a97735614941e9ca7fa2f221f8db9a12b2.1624421816.git.viresh.kumar@linaro.org>
Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> Subject: Re: [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback instead of ->stop_cpu()
Typo in subject should be "powernv".
cheers
^ permalink raw reply
* [PATCH V4.1 3/4] cpufreq: powernv: Migrate to ->exit() callback instead of ->stop_cpu()
From: Viresh Kumar @ 2021-06-23 6:01 UTC (permalink / raw)
To: Rafael Wysocki, Viresh Kumar, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, Vincent Guittot, linux-kernel, linux-pm
In-Reply-To: <e40e57a97735614941e9ca7fa2f221f8db9a12b2.1624421816.git.viresh.kumar@linaro.org>
commit 367dc4aa932b ("cpufreq: Add stop CPU callback to cpufreq_driver
interface") added the stop_cpu() callback to allow the drivers to do
clean up before the CPU is completely down and its state can't be
modified.
At that time the CPU hotplug framework used to call the cpufreq core's
registered notifier for different events like CPU_DOWN_PREPARE and
CPU_POST_DEAD. The stop_cpu() callback was called during the
CPU_DOWN_PREPARE event.
This is no longer the case, cpuhp_cpufreq_offline() is called only once
by the CPU hotplug core now and we don't really need two separate
callbacks for cpufreq drivers, i.e. stop_cpu() and exit(), as everything
can be done from the exit() callback itself.
Migrate to using the exit() callback instead of stop_cpu().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V4->V4.1:
- s/powerenv/powernv/
drivers/cpufreq/powernv-cpufreq.c | 23 +++++++++--------------
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index e439b43c19eb..005600cef273 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -875,7 +875,15 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
static int powernv_cpufreq_cpu_exit(struct cpufreq_policy *policy)
{
- /* timer is deleted in cpufreq_cpu_stop() */
+ struct powernv_smp_call_data freq_data;
+ struct global_pstate_info *gpstates = policy->driver_data;
+
+ freq_data.pstate_id = idx_to_pstate(powernv_pstate_info.min);
+ freq_data.gpstate_id = idx_to_pstate(powernv_pstate_info.min);
+ smp_call_function_single(policy->cpu, set_pstate, &freq_data, 1);
+ if (gpstates)
+ del_timer_sync(&gpstates->timer);
+
kfree(policy->driver_data);
return 0;
@@ -1007,18 +1015,6 @@ static struct notifier_block powernv_cpufreq_opal_nb = {
.priority = 0,
};
-static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)
-{
- struct powernv_smp_call_data freq_data;
- struct global_pstate_info *gpstates = policy->driver_data;
-
- freq_data.pstate_id = idx_to_pstate(powernv_pstate_info.min);
- freq_data.gpstate_id = idx_to_pstate(powernv_pstate_info.min);
- smp_call_function_single(policy->cpu, set_pstate, &freq_data, 1);
- if (gpstates)
- del_timer_sync(&gpstates->timer);
-}
-
static unsigned int powernv_fast_switch(struct cpufreq_policy *policy,
unsigned int target_freq)
{
@@ -1042,7 +1038,6 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.target_index = powernv_cpufreq_target_index,
.fast_switch = powernv_fast_switch,
.get = powernv_cpufreq_get,
- .stop_cpu = powernv_cpufreq_stop_cpu,
.attr = powernv_cpu_freq_attr,
};
--
2.31.1.272.g89b43f80a514
^ permalink raw reply related
* Re: [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback instead of ->stop_cpu()
From: Viresh Kumar @ 2021-06-23 6:01 UTC (permalink / raw)
To: Michael Ellerman
Cc: Vincent Guittot, linux-pm, Rafael Wysocki, linux-kernel,
Paul Mackerras, linuxppc-dev
In-Reply-To: <87v96516d9.fsf@mpe.ellerman.id.au>
On 23-06-21, 15:45, Michael Ellerman wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
> >
> > Subject: Re: [PATCH V4 3/4] cpufreq: powerenv: Migrate to ->exit() callback instead of ->stop_cpu()
>
> Typo in subject should be "powernv".
Thanks for noticing it :)
--
viresh
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/papr_scm: Properly handle UUID types and API
From: Michael Ellerman @ 2021-06-23 6:03 UTC (permalink / raw)
To: Andy Shevchenko, linuxppc-dev, linux-kernel
Cc: Oliver O'Halloran, Paul Mackerras, Aneesh Kumar K . V
In-Reply-To: <YNHbSGzdgQh+6F+O@smile.fi.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> On Wed, Jun 16, 2021 at 04:43:03PM +0300, Andy Shevchenko wrote:
>> Parse to and export from UUID own type, before dereferencing.
>> This also fixes wrong comment (Little Endian UUID is something else)
>> and should eliminate the direct strict types assignments.
>
> Any comments on this version? Can it be applied?
Yeah I'll grab it.
cheers
^ permalink raw reply
* linux-next: manual merge of the kvm-arm tree with the powerpc and kvm trees
From: Stephen Rothwell @ 2021-06-23 6:04 UTC (permalink / raw)
To: Christoffer Dall, Marc Zyngier, Michael Ellerman, PowerPC,
Paolo Bonzini, KVM
Cc: Ashish Kalra, Brijesh Singh, Sean Christopherson,
Linux Kernel Mailing List, Bharata B Rao, Linux Next Mailing List,
Vitaly Kuznetsov, Steven Price
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
include/uapi/linux/kvm.h
between commits:
b87cc116c7e1 ("KVM: PPC: Book3S HV: Add KVM_CAP_PPC_RPT_INVALIDATE capability")
644f706719f0 ("KVM: x86: hyper-v: Introduce KVM_CAP_HYPERV_ENFORCE_CPUID")
0dbb11230437 ("KVM: X86: Introduce KVM_HC_MAP_GPA_RANGE hypercall")
from the powerpc and kvm trees and commit:
ea7fc1bb1cd1 ("KVM: arm64: Introduce MTE VM feature")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/uapi/linux/kvm.h
index 330835f1005b,da1edd2b4046..000000000000
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -1083,10 -1083,7 +1083,11 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_SGX_ATTRIBUTE 196
#define KVM_CAP_VM_COPY_ENC_CONTEXT_FROM 197
#define KVM_CAP_PTP_KVM 198
-#define KVM_CAP_ARM_MTE 199
+#define KVM_CAP_HYPERV_ENFORCE_CPUID 199
+#define KVM_CAP_SREGS2 200
+#define KVM_CAP_EXIT_HYPERCALL 201
+#define KVM_CAP_PPC_RPT_INVALIDATE 202
++#define KVM_CAP_ARM_MTE 203
#ifdef KVM_CAP_IRQ_ROUTING
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v8 4/6] KVM: PPC: Book3S HV: Nested support in H_RPT_INVALIDATE
From: Michael Ellerman @ 2021-06-23 6:47 UTC (permalink / raw)
To: bharata, Nathan Chancellor, kvm-ppc, linuxppc-dev, farosas,
aneesh.kumar, npiggin, david
In-Reply-To: <YNGNWRsUgRiMqrGs@in.ibm.com>
Bharata B Rao <bharata@linux.ibm.com> writes:
> On Tue, Jun 22, 2021 at 10:05:45AM +0530, Bharata B Rao wrote:
>> On Mon, Jun 21, 2021 at 10:12:42AM -0700, Nathan Chancellor wrote:
>> > I have not seen this reported yet so apologies if it has and there is a
>> > fix I am missing:
>> >
>> > arch/powerpc/kvm/book3s_hv_nested.c:1334:11: error: variable 'ap' is uninitialized when used here [-Werror,-Wuninitialized]
>> > ap, start, end);
>> > ^~
>> > arch/powerpc/kvm/book3s_hv_nested.c:1276:25: note: initialize the variable 'ap' to silence this warning
>> > unsigned long psize, ap;
>> > ^
>> > = 0
>>
>> Thanks for catching this, this wasn't caught in my environment.
>>
>> I will repost the series with proper initialization to ap.
>
> Michael,
>
> Here is the fix for this on top of powerpc/next. If it is easier
> and cleaner to fold this into the original series and re-post
> the whole series against any updated tree, let me know.
Thanks. I squashed this in.
cheers
> From 2e7198e28c0d1137f3230d4645e9cfddaccf4987 Mon Sep 17 00:00:00 2001
> From: Bharata B Rao <bharata@linux.ibm.com>
> Date: Tue, 22 Jun 2021 12:07:01 +0530
> Subject: [PATCH 1/1] KVM: PPC: Book3S HV: Use proper ap value in
> H_RPT_INVALIDATE
>
> The ap value that is used when performing range based partition
> scoped invalidations for the nested guests wasn't initialized
> correctly.
>
> Fix this and while we are here, reorganize the routine that does
> this invalidation for better readability.
>
> Fixes: 0e67d866cb32 ("KVM: PPC: Book3S HV: Nested support in H_RPT_INVALIDATE")
> Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv_nested.c | 90 +++++++++++++----------------
> 1 file changed, 40 insertions(+), 50 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_nested.c b/arch/powerpc/kvm/book3s_hv_nested.c
> index d78efb5f5bb3..3a06ac0b53e2 100644
> --- a/arch/powerpc/kvm/book3s_hv_nested.c
> +++ b/arch/powerpc/kvm/book3s_hv_nested.c
> @@ -1222,27 +1222,6 @@ long kvmhv_do_nested_tlbie(struct kvm_vcpu *vcpu)
> return H_SUCCESS;
> }
>
> -static long do_tlb_invalidate_nested_tlb(struct kvm_vcpu *vcpu,
> - unsigned long lpid,
> - unsigned long page_size,
> - unsigned long ap,
> - unsigned long start,
> - unsigned long end)
> -{
> - unsigned long addr = start;
> - int ret;
> -
> - do {
> - ret = kvmhv_emulate_tlbie_tlb_addr(vcpu, lpid, ap,
> - get_epn(addr));
> - if (ret)
> - return ret;
> - addr += page_size;
> - } while (addr < end);
> -
> - return ret;
> -}
> -
> static long do_tlb_invalidate_nested_all(struct kvm_vcpu *vcpu,
> unsigned long lpid, unsigned long ric)
> {
> @@ -1263,6 +1242,42 @@ static long do_tlb_invalidate_nested_all(struct kvm_vcpu *vcpu,
> */
> static unsigned long tlb_range_flush_page_ceiling __read_mostly = 33;
>
> +static long do_tlb_invalidate_nested_tlb(struct kvm_vcpu *vcpu,
> + unsigned long lpid,
> + unsigned long pg_sizes,
> + unsigned long start,
> + unsigned long end)
> +{
> + int ret = H_P4;
> + unsigned long addr, nr_pages;
> + struct mmu_psize_def *def;
> + unsigned long psize, ap, page_size;
> + bool flush_lpid;
> +
> + for (psize = 0; psize < MMU_PAGE_COUNT; psize++) {
> + def = &mmu_psize_defs[psize];
> + if (!(pg_sizes & def->h_rpt_pgsize))
> + continue;
> +
> + nr_pages = (end - start) >> def->shift;
> + flush_lpid = nr_pages > tlb_range_flush_page_ceiling;
> + if (flush_lpid)
> + return do_tlb_invalidate_nested_all(vcpu, lpid,
> + RIC_FLUSH_TLB);
> + addr = start;
> + ap = mmu_get_ap(psize);
> + page_size = 1UL << def->shift;
> + do {
> + ret = kvmhv_emulate_tlbie_tlb_addr(vcpu, lpid, ap,
> + get_epn(addr));
> + if (ret)
> + return H_P4;
> + addr += page_size;
> + } while (addr < end);
> + }
> + return ret;
> +}
> +
> /*
> * Performs partition-scoped invalidations for nested guests
> * as part of H_RPT_INVALIDATE hcall.
> @@ -1271,10 +1286,6 @@ long do_h_rpt_invalidate_pat(struct kvm_vcpu *vcpu, unsigned long lpid,
> unsigned long type, unsigned long pg_sizes,
> unsigned long start, unsigned long end)
> {
> - struct kvm_nested_guest *gp;
> - long ret;
> - unsigned long psize, ap;
> -
> /*
> * If L2 lpid isn't valid, we need to return H_PARAMETER.
> *
> @@ -1284,8 +1295,7 @@ long do_h_rpt_invalidate_pat(struct kvm_vcpu *vcpu, unsigned long lpid,
> * H_ENTER_NESTED call. Since we can't differentiate this case from
> * the invalid case, we ignore such flush requests and return success.
> */
> - gp = kvmhv_find_nested(vcpu->kvm, lpid);
> - if (!gp)
> + if (!kvmhv_find_nested(vcpu->kvm, lpid))
> return H_SUCCESS;
>
> /*
> @@ -1313,29 +1323,9 @@ long do_h_rpt_invalidate_pat(struct kvm_vcpu *vcpu, unsigned long lpid,
> if (start == 0 && end == -1)
> return do_tlb_invalidate_nested_all(vcpu, lpid, RIC_FLUSH_TLB);
>
> - if (type & H_RPTI_TYPE_TLB) {
> - struct mmu_psize_def *def;
> - bool flush_lpid;
> - unsigned long nr_pages;
> -
> - for (psize = 0; psize < MMU_PAGE_COUNT; psize++) {
> - def = &mmu_psize_defs[psize];
> - if (!(pg_sizes & def->h_rpt_pgsize))
> - continue;
> -
> - nr_pages = (end - start) >> def->shift;
> - flush_lpid = nr_pages > tlb_range_flush_page_ceiling;
> - if (flush_lpid)
> - return do_tlb_invalidate_nested_all(vcpu, lpid,
> - RIC_FLUSH_TLB);
> -
> - ret = do_tlb_invalidate_nested_tlb(vcpu, lpid,
> - (1UL << def->shift),
> - ap, start, end);
> - if (ret)
> - return H_P4;
> - }
> - }
> + if (type & H_RPTI_TYPE_TLB)
> + return do_tlb_invalidate_nested_tlb(vcpu, lpid, pg_sizes,
> + start, end);
> return H_SUCCESS;
> }
>
> --
> 2.31.1
^ permalink raw reply
* Re: [powerpc][next-20210621] WARNING at kernel/sched/fair.c:3277 during boot
From: Vincent Guittot @ 2021-06-23 7:19 UTC (permalink / raw)
To: Sachin Sant; +Cc: Odin Ugedal, Linux Next Mailing List, linuxppc-dev, open list
In-Reply-To: <53968DDE-9E93-4CB4-B5E4-526230B6E154@linux.vnet.ibm.com>
Hi Sachin,
Le mardi 22 juin 2021 à 21:29:36 (+0530), Sachin Sant a écrit :
> >> On Tue, 22 Jun 2021 at 09:39, Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
> >>>
> >>> While booting 5.13.0-rc7-next-20210621 on a PowerVM LPAR following warning
> >>> is seen
> >>>
> >>> [ 30.922154] ------------[ cut here ]------------
> >>> [ 30.922201] cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg
> >>> [ 30.922219] WARNING: CPU: 6 PID: 762 at kernel/sched/fair.c:3277 update_blocked_averages+0x758/0x780
> >>
> >> Yes. That was exactly the purpose of the patch. There is one last
> >> remaining part which could generate this. I'm going to prepare a patch
> >
> > Could you try the patch below ? I have been able to reproduce the problem locally and this
> > fix it on my system:
> >
> I can recreate the issue with this patch.
ok, so your problem seem to be different from my assumption. Could you try
the patch below on top of the previous one ?
This will help us to confirm that the problem comes from load_avg and that
it's linked to the cfs load_avg and it's not a problem happening earlier in
the update of PELT.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index da91db1c137f..8a6566f945a0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3030,8 +3030,9 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
static inline void
enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
+ u32 divider = get_pelt_divider(&se->avg);
cfs_rq->avg.load_avg += se->avg.load_avg;
- cfs_rq->avg.load_sum += se_weight(se) * se->avg.load_sum;
+ cfs_rq->avg.load_sum = cfs_rq->avg.load_avg * divider;
}
static inline void
@@ -3304,9 +3305,9 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
* Make sure that rounding and/or propagation of PELT values never
* break this.
*/
- SCHED_WARN_ON(cfs_rq->avg.load_avg ||
- cfs_rq->avg.util_avg ||
- cfs_rq->avg.runnable_avg);
+ SCHED_WARN_ON(cfs_rq->avg.load_avg);
+ SCHED_WARN_ON(cfs_rq->avg.util_avg);
+ SCHED_WARN_ON(cfs_rq->avg.runnable_avg);
return true;
}
>
> Starting Terminate Plymouth Boot Screen...
> Starting Hold until boot process finishes up...
> [FAILED] Failed to start Crash recovery kernel arming.
> See 'systemctl status kdump.service' for details.
> [ 10.737913] ------------[ cut here ]------------
> [ 10.737960] cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg
> [ 10.737976] WARNING: CPU: 27 PID: 146 at kernel/sched/fair.c:3279 update_blocked_averages+0x758/0x780
> [ 10.738010] Modules linked in: stp llc rfkill sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod fuse
> [ 10.738089] CPU: 27 PID: 146 Comm: ksoftirqd/27 Not tainted 5.13.0-rc7-next-20210621-dirty #2
> [ 10.738103] NIP: c0000000001b2768 LR: c0000000001b2764 CTR: c000000000729120
> [ 10.738116] REGS: c000000015973840 TRAP: 0700 Not tainted (5.13.0-rc7-next-20210621-dirty)
> [ 10.738130] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48000224 XER: 00000005
> [ 10.738161] CFAR: c00000000014d120 IRQMASK: 1
> [ 10.738161] GPR00: c0000000001b2764 c000000015973ae0 c0000000029bb900 0000000000000048
> [ 10.738161] GPR04: 00000000fffeffff c0000000159737a0 0000000000000027 c00000154f9f7e18
> [ 10.738161] GPR08: 0000000000000023 0000000000000001 0000000000000027 c00000167f1d7fe8
> [ 10.738161] GPR12: 0000000000000000 c00000154ffd7e80 c00000154fa82580 000000000000b78a
> [ 10.738161] GPR16: 000000028007883c 00000000000002ed c000000038d31000 0000000000000000
> [ 10.738161] GPR20: 0000000000000000 c0000000029fdfe0 0000000000000000 000000000000037b
> [ 10.738161] GPR24: 0000000000000000 c00000154fa82f90 0000000000000001 c00000003d4ca400
> [ 10.738161] GPR28: 00000000000002ed c000000038d311c0 c000000038d31100 0000000000000000
> [ 10.738281] NIP [c0000000001b2768] update_blocked_averages+0x758/0x780
> [ 10.738290] LR [c0000000001b2764] update_blocked_averages+0x754/0x780
> [ 10.738299] Call Trace:
> [ 10.738303] [c000000015973ae0] [c0000000001b2764] update_blocked_averages+0x754/0x780 (unreliable)
> [ 10.738315] [c000000015973c00] [c0000000001be720] run_rebalance_domains+0xa0/0xd0
> [ 10.738326] [c000000015973c30] [c000000000cf9acc] __do_softirq+0x15c/0x3d4
> [ 10.738337] [c000000015973d20] [c000000000158464] run_ksoftirqd+0x64/0x90
> [ 10.738346] [c000000015973d40] [c00000000018fd24] smpboot_thread_fn+0x204/0x270
> [ 10.738357] [c000000015973da0] [c000000000189770] kthread+0x190/0x1a0
> [ 10.738367] [c000000015973e10] [c00000000000ceec] ret_from_kernel_thread+0x5c/0x70
> [ 10.738381] Instruction dump:
> [ 10.738388] 3863c808 9be9eefe 4bf9a979 60000000 0fe00000 4bfff980 e9210070 e8610088
> [ 10.738410] 39400001 99490003 4bf9a959 60000000 <0fe00000> 4bfffc24 3d22fff6 8929eefb
> [ 10.738431] ---[ end trace 9ca80b55840c53f0 ]—
>
> Thanks
> -Sachin
>
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 8cc27b847ad8..da91db1c137f 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3037,8 +3037,9 @@ enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > static inline void
> > dequeue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> > {
> > + u32 divider = get_pelt_divider(&se->avg);
> > sub_positive(&cfs_rq->avg.load_avg, se->avg.load_avg);
> > - sub_positive(&cfs_rq->avg.load_sum, se_weight(se) * se->avg.load_sum);
> > + cfs_rq->avg.load_sum = cfs_rq->avg.load_avg * divider;
> > }
> > #else
> > static inline void
> >
^ permalink raw reply related
* Re: [powerpc][next-20210621] WARNING at kernel/sched/fair.c:3277 during boot
From: Sachin Sant @ 2021-06-23 7:58 UTC (permalink / raw)
To: Vincent Guittot
Cc: Odin Ugedal, Linux Next Mailing List, linuxppc-dev, open list
In-Reply-To: <20210623071935.GA29143@vingu-book>
>>> Could you try the patch below ? I have been able to reproduce the problem locally and this
>>> fix it on my system:
>>>
>> I can recreate the issue with this patch.
>
> ok, so your problem seem to be different from my assumption. Could you try
> the patch below on top of the previous one ?
>
> This will help us to confirm that the problem comes from load_avg and that
> it's linked to the cfs load_avg and it's not a problem happening earlier in
> the update of PELT.
>
Indeed. With both the patches applied I see following warning related to load_avg
Starting NTP client/server...
Starting VDO volume services...
[ 9.029054] ------------[ cut here ]------------
[ 9.029084] cfs_rq->avg.load_avg
[ 9.029111] WARNING: CPU: 21 PID: 1169 at kernel/sched/fair.c:3282 update_blocked_averages+0x760/0x830
[ 9.029151] Modules linked in: pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod fuse
[ 9.029233] CPU: 21 PID: 1169 Comm: grep Not tainted 5.13.0-rc7-next-20210621-dirty #3
[ 9.029246] NIP: c0000000001b6150 LR: c0000000001b614c CTR: c000000000728f40
[ 9.029259] REGS: c00000000e177650 TRAP: 0700 Not tainted (5.13.0-rc7-next-20210621-dirty)
[ 9.029271] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 48088224 XER: 00000005
[ 9.029296] CFAR: c00000000014d120 IRQMASK: 1
[ 9.029296] GPR00: c0000000001b614c c00000000e1778f0 c0000000029bb900 0000000000000014
[ 9.029296] GPR04: 00000000fffeffff c00000000e1775b0 0000000000000027 c00000154f637e18
[ 9.029296] GPR08: 0000000000000023 0000000000000001 0000000000000027 c00000167f1d7fe8
[ 9.029296] GPR12: 0000000000008000 c00000154ffe0e80 000000000000b820 000000021a2c6864
[ 9.029296] GPR16: c0000000482cc000 c00000154f6c2580 0000000000000001 0000000000000000
[ 9.029296] GPR20: c00000000291a7f9 c0000000482cc100 0000000000000000 000000000000020d
[ 9.029296] GPR24: 0000000000000000 c00000154f6c2f90 0000000000000001 c000000030b84400
[ 9.029296] GPR28: 000000000000020d c0000000482cc1c0 0000000000000338 0000000000000000
[ 9.029481] NIP [c0000000001b6150] update_blocked_averages+0x760/0x830
[ 9.029494] LR [c0000000001b614c] update_blocked_averages+0x75c/0x830
[ 9.029508] Call Trace:
[ 9.029515] [c00000000e1778f0] [c0000000001b614c] update_blocked_averages+0x75c/0x830 (unreliable)
[ 9.029533] [c00000000e177a20] [c0000000001bd388] newidle_balance+0x258/0x5c0
[ 9.029542] [c00000000e177ab0] [c0000000001bd7cc] pick_next_task_fair+0x7c/0x4c0
[ 9.029574] [c00000000e177b10] [c000000000cee3dc] __schedule+0x15c/0x1780
[ 9.029599] [c00000000e177c50] [c0000000001a5984] do_task_dead+0x64/0x70
[ 9.029622] [c00000000e177c80] [c000000000156338] do_exit+0x848/0xcc0
[ 9.029646] [c00000000e177d50] [c000000000156884] do_group_exit+0x64/0xe0
[ 9.029666] [c00000000e177d90] [c000000000156924] sys_exit_group+0x24/0x30
[ 9.029688] [c00000000e177db0] [c0000000000310c0] system_call_exception+0x150/0x2d0
Startin[ 9.029710] [gc00000000e177e10 Hardware Monito] [c00000000000_common+0xec/0x2lling Sensors...
78
[ 9.029743] --- interrupt: c00 at 0x7fff943fddcc
[ 9.029758] NIP: 00007fff943fddcc LR: 00007fff94357f04 CTR: 0000000000000000
[ 9.029786] REGS: c00000000e177e80 TRAP: 0c00 Not tainted (5.13.0-rc7-next-20210621-dirty)
[ 9.029798] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 28000402 XER: 00000000
[ 9.029825] IRQMASK: 0
[ 9.029825] GPR00: 00000000000000ea 00007ffff59c0170 00007fff94527100 0000000000000001
[ 9.029825] GPR04: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
[ 9.029825] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 9.029825] GPR12: 0000000000000000 00007fff9466af00 0000000000000000 0000000000000000
[ 9.029825] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 9.029825] GPR20: 0000000000000000 00007fff94524f98 0000000000000002 0000000000000001
[ 9.029825] GPR24: 00007fff94520950 0000000000000000 0000000000000001 0000000000000001
[ 9.029825] GPR28: 0000000000000000 0000000000000000 00007fff94663f10 0000000000000001
[ 9.029935] NIP [00007fff943fddcc] 0x7fff943fddcc
[ 9.029944] LR [00007fff94357f04] 0x7fff94357f04
[ 9.029952] --- interrupt: c00
[ 9.029959] Instruction dump:
[ 9.029966] 0fe00000 4bfffc64 60000000 60000000 89340007 2f890000 409efc38 e8610098
[ 9.029987] 39200001 99340007 4bf96f71 60000000 <0fe00000> 4bfffc1c 60000000 60000000
[ 9.030013] ---[ end trace 3d7e3a29c9539d96 ]---
Starting Authorization Manager…
Thanks
-Sachin
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index da91db1c137f..8a6566f945a0 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3030,8 +3030,9 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
> static inline void
> enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
> {
> + u32 divider = get_pelt_divider(&se->avg);
> cfs_rq->avg.load_avg += se->avg.load_avg;
> - cfs_rq->avg.load_sum += se_weight(se) * se->avg.load_sum;
> + cfs_rq->avg.load_sum = cfs_rq->avg.load_avg * divider;
> }
>
> static inline void
> @@ -3304,9 +3305,9 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
> * Make sure that rounding and/or propagation of PELT values never
> * break this.
> */
> - SCHED_WARN_ON(cfs_rq->avg.load_avg ||
> - cfs_rq->avg.util_avg ||
> - cfs_rq->avg.runnable_avg);
> + SCHED_WARN_ON(cfs_rq->avg.load_avg);
> + SCHED_WARN_ON(cfs_rq->avg.util_avg);
> + SCHED_WARN_ON(cfs_rq->avg.runnable_avg);
>
> return true;
> }
>
>
>>
>> Starting Terminate Plymouth Boot Screen...
>> Starting Hold until boot process finishes up...
>> [FAILED] Failed to start Crash recovery kernel arming.
>> See 'systemctl status kdump.service' for details.
>> [ 10.737913] ------------[ cut here ]------------
>> [ 10.737960] cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg
>> [ 10.737976] WARNING: CPU: 27 PID: 146 at kernel/sched/fair.c:3279 update_blocked_averages+0x758/0x780
>> [ 10.738010] Modules linked in: stp llc rfkill sunrpc pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg ibmvscsi ibmveth scsi_transport_srp dm_mirror dm_region_hash dm_log dm_mod fuse
>> [ 10.738089] CPU: 27 PID: 146 Comm: ksoftirqd/27 Not tainted 5.13.0-rc7-next-20210621-dirty #2
>> [ 10.738103] NIP: c0000000001b2768 LR: c0000000001b2764 CTR: c000000000729120
>> [ 10.738116] REGS: c000000015973840 TRAP: 0700 Not tainted (5.13.0-rc7-next-20210621-dirty)
>> [ 10.738130] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48000224 XER: 00000005
>> [ 10.738161] CFAR: c00000000014d120 IRQMASK: 1
>> [ 10.738161] GPR00: c0000000001b2764 c000000015973ae0 c0000000029bb900 0000000000000048
>> [ 10.738161] GPR04: 00000000fffeffff c0000000159737a0 0000000000000027 c00000154f9f7e18
>> [ 10.738161] GPR08: 0000000000000023 0000000000000001 0000000000000027 c00000167f1d7fe8
>> [ 10.738161] GPR12: 0000000000000000 c00000154ffd7e80 c00000154fa82580 000000000000b78a
>> [ 10.738161] GPR16: 000000028007883c 00000000000002ed c000000038d31000 0000000000000000
>> [ 10.738161] GPR20: 0000000000000000 c0000000029fdfe0 0000000000000000 000000000000037b
>> [ 10.738161] GPR24: 0000000000000000 c00000154fa82f90 0000000000000001 c00000003d4ca400
>> [ 10.738161] GPR28: 00000000000002ed c000000038d311c0 c000000038d31100 0000000000000000
>> [ 10.738281] NIP [c0000000001b2768] update_blocked_averages+0x758/0x780
>> [ 10.738290] LR [c0000000001b2764] update_blocked_averages+0x754/0x780
>> [ 10.738299] Call Trace:
>> [ 10.738303] [c000000015973ae0] [c0000000001b2764] update_blocked_averages+0x754/0x780 (unreliable)
>> [ 10.738315] [c000000015973c00] [c0000000001be720] run_rebalance_domains+0xa0/0xd0
>> [ 10.738326] [c000000015973c30] [c000000000cf9acc] __do_softirq+0x15c/0x3d4
>> [ 10.738337] [c000000015973d20] [c000000000158464] run_ksoftirqd+0x64/0x90
>> [ 10.738346] [c000000015973d40] [c00000000018fd24] smpboot_thread_fn+0x204/0x270
>> [ 10.738357] [c000000015973da0] [c000000000189770] kthread+0x190/0x1a0
>> [ 10.738367] [c000000015973e10] [c00000000000ceec] ret_from_kernel_thread+0x5c/0x70
>> [ 10.738381] Instruction dump:
>> [ 10.738388] 3863c808 9be9eefe 4bf9a979 60000000 0fe00000 4bfff980 e9210070 e8610088
>> [ 10.738410] 39400001 99490003 4bf9a959 60000000 <0fe00000> 4bfffc24 3d22fff6 8929eefb
>> [ 10.738431] ---[ end trace 9ca80b55840c53f0 ]—
>>
>> Thanks
>> -Sachin
>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 8cc27b847ad8..da91db1c137f 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -3037,8 +3037,9 @@ enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
>>> static inline void
>>> dequeue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
>>> {
>>> + u32 divider = get_pelt_divider(&se->avg);
>>> sub_positive(&cfs_rq->avg.load_avg, se->avg.load_avg);
>>> - sub_positive(&cfs_rq->avg.load_sum, se_weight(se) * se->avg.load_sum);
>>> + cfs_rq->avg.load_sum = cfs_rq->avg.load_avg * divider;
>>> }
>>> #else
>>> static inline void
^ permalink raw reply
* Re: [PATCH v3 0/4] Add perf interface to expose nvdimm
From: kajoljain @ 2021-06-23 8:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: nvdimm, santosh, maddy, ira.weiny, rnsastry, linux-kernel,
atrajeev, aneesh.kumar, vaibhav, dan.j.williams, linuxppc-dev,
tglx
In-Reply-To: <YNHiRO11E9yYS6mv@hirez.programming.kicks-ass.net>
On 6/22/21 6:44 PM, Peter Zijlstra wrote:
> On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote:
>> ---
>> Kajol Jain (4):
>> drivers/nvdimm: Add nvdimm pmu structure
>> drivers/nvdimm: Add perf interface to expose nvdimm performance stats
>> powerpc/papr_scm: Add perf interface support
>> powerpc/papr_scm: Document papr_scm sysfs event format entries
>
> Don't see anything obviously wrong with this one.
>
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>
Hi Peter,
Thanks for reviewing the patch. Can you help me on how to take
these patches to linus tree or can you take it?
Thanks,
Kajol Jain
^ permalink raw reply
* Re: [PATCH v3 0/4] Add perf interface to expose nvdimm
From: Peter Zijlstra @ 2021-06-23 8:31 UTC (permalink / raw)
To: kajoljain
Cc: nvdimm, santosh, maddy, ira.weiny, rnsastry, linux-kernel,
atrajeev, aneesh.kumar, vaibhav, dan.j.williams, linuxppc-dev,
tglx
In-Reply-To: <cea827fe-62d4-95fe-b81f-5c7bebe4a6f0@linux.ibm.com>
On Wed, Jun 23, 2021 at 01:40:38PM +0530, kajoljain wrote:
>
>
> On 6/22/21 6:44 PM, Peter Zijlstra wrote:
> > On Thu, Jun 17, 2021 at 06:56:13PM +0530, Kajol Jain wrote:
> >> ---
> >> Kajol Jain (4):
> >> drivers/nvdimm: Add nvdimm pmu structure
> >> drivers/nvdimm: Add perf interface to expose nvdimm performance stats
> >> powerpc/papr_scm: Add perf interface support
> >> powerpc/papr_scm: Document papr_scm sysfs event format entries
> >
> > Don't see anything obviously wrong with this one.
> >
> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> >
>
> Hi Peter,
> Thanks for reviewing the patch. Can you help me on how to take
> these patches to linus tree or can you take it?
I would expect either the NVDIMM or PPC maintainers to take this. Dan,
Michael ?
^ permalink raw reply
* Re: [PATCH v14 00/12] Restricted DMA
From: Konrad Rzeszutek Wilk @ 2021-06-23 8:38 UTC (permalink / raw)
To: Claire Chang
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, sstabellini, Saravana Kannan, Joerg Roedel,
Rafael J . Wysocki, Christoph Hellwig, Bartosz Golaszewski,
bskeggs, linux-pci, xen-devel, Thierry Reding, intel-gfx,
matthew.auld, linux-devicetree, jxgao, daniel, Will Deacon,
maarten.lankhorst, airlied, Dan Williams, linuxppc-dev,
jani.nikula, Rob Herring, rodrigo.vivi, bhelgaas, boris.ostrovsky,
Andy Shevchenko, jgross, Nicolas Boichat, Greg KH, Randy Dunlap,
lkml, tfiga, list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
thomas.lendacky, Robin Murphy, bauerman
In-Reply-To: <20210619034043.199220-1-tientzu@chromium.org>
On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or unexpected addresses, possibly
> leading to data leakage or corruption.
>
> For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is
> not behind an IOMMU. As PCI-e, by design, gives the device full access to
> system memory, a vulnerability in the Wi-Fi firmware could easily escalate
> to a full system exploit (remote wifi exploits: [1a], [1b] that shows a
> full chain of exploits; [2], [3]).
>
> To mitigate the security concerns, we introduce restricted DMA. Restricted
> DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a
> specially allocated region and does memory allocation from the same region.
> The feature on its own provides a basic level of protection against the DMA
> overwriting buffer contents at unexpected times. However, to protect
> against general data leakage and system memory corruption, the system needs
> to provide a way to restrict the DMA to a predefined memory region (this is
> usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]).
>
> [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
> [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
> [2] https://blade.tencent.com/en/advisories/qualpwn/
> [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/
> [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132
Heya Claire,
I put all your patches on
https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/log/?h=devel/for-linus-5.14
Please double-check that they all look ok.
Thank you!
^ permalink raw reply
* Re: [PATCH v14 00/12] Restricted DMA
From: Claire Chang @ 2021-06-23 9:01 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, Frank Rowand, mingo,
Marek Szyprowski, Stefano Stabellini, Saravana Kannan,
Joerg Roedel, Rafael J . Wysocki, Christoph Hellwig,
Bartosz Golaszewski, bskeggs, linux-pci, xen-devel,
Thierry Reding, intel-gfx, matthew.auld, linux-devicetree,
Jianxiong Gao, Daniel Vetter, Will Deacon, maarten.lankhorst,
airlied, Dan Williams, linuxppc-dev, jani.nikula, Rob Herring,
rodrigo.vivi, Bjorn Helgaas, boris.ostrovsky, Andy Shevchenko,
jgross, Nicolas Boichat, Greg KH, Randy Dunlap, lkml, Tomasz Figa,
list@263.net:IOMMU DRIVERS, Jim Quinlan, xypron.glpk,
Tom Lendacky, Robin Murphy, bauerman
In-Reply-To: <YNLy7z0Zq1AXKLng@char.us.oracle.com>
On Wed, Jun 23, 2021 at 4:38 PM Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>
> On Sat, Jun 19, 2021 at 11:40:31AM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory at unexpected times and/or unexpected addresses, possibly
> > leading to data leakage or corruption.
> >
> > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is
> > not behind an IOMMU. As PCI-e, by design, gives the device full access to
> > system memory, a vulnerability in the Wi-Fi firmware could easily escalate
> > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a
> > full chain of exploits; [2], [3]).
> >
> > To mitigate the security concerns, we introduce restricted DMA. Restricted
> > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a
> > specially allocated region and does memory allocation from the same region.
> > The feature on its own provides a basic level of protection against the DMA
> > overwriting buffer contents at unexpected times. However, to protect
> > against general data leakage and system memory corruption, the system needs
> > to provide a way to restrict the DMA to a predefined memory region (this is
> > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]).
> >
> > [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
> > [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
> > [2] https://blade.tencent.com/en/advisories/qualpwn/
> > [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/
> > [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132
>
> Heya Claire,
>
> I put all your patches on
> https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/log/?h=devel/for-linus-5.14
>
> Please double-check that they all look ok.
>
> Thank you!
They look fine. Thank you!
^ permalink raw reply
* Re: [PATCH v15 2/4] kasan: allow architectures to provide an outline readiness check
From: Daniel Axtens @ 2021-06-23 9:25 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Marco Elver, aneesh.kumar, LKML, kasan-dev,
Linux Memory Management List, Andrew Morton, linuxppc-dev
In-Reply-To: <CA+fCnZdJ=HHn1Y=UDiYJ2NagNF9d-bJfjQa0jmiDaLiqneB_rA@mail.gmail.com>
>> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
>> index 10177cc26d06..0ad615f3801d 100644
>> --- a/mm/kasan/common.c
>> +++ b/mm/kasan/common.c
>> @@ -331,6 +331,10 @@ static inline bool ____kasan_slab_free(struct kmem_cache *cache, void *object,
>> u8 tag;
>> void *tagged_object;
>>
>> + /* Bail if the arch isn't ready */
>
> This comment brings no value. The fact that we bail is clear from the
> following line. The comment should explain why we bail.
>
>> + if (!kasan_arch_is_ready())
>> + return false;
Fair enough, I've just dropped the comments as I don't think there's
really a lot of scope for the generic/core comment to explain why a
particular architecture might not be ready.
> Have you considered including these checks into the high-level
> wrappers in include/linux/kasan.h? Would that work?
I don't think those wrappers will catch the outline check functions
like __asan_load*, which also need guarding.
Kind regards,
Daniel
^ permalink raw reply
* Re: nand: WARNING: a0000000.nand: the ECC used on your system (1b/256B) is too weak compared to the one required by the NAND chip (4b/512B)
From: Christophe Leroy @ 2021-06-23 9:41 UTC (permalink / raw)
To: Miquel Raynal; +Cc: linuxppc-dev@lists.ozlabs.org, linux-mtd
In-Reply-To: <20210618225032.69cdc30c@xps13>
Le 19/06/2021 à 20:40, Miquel Raynal a écrit :
> Hi Christophe,
>
>>>> Now and then I'm using one of the latest kernels (Today is 5.13-rc6), and sometime in one of the 5.x releases, I started to get errors like:
>>>>
>>>> [ 5.098265] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.103859] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 60
>>>> bytes from PEB 99:59824, read only 60 bytes, retry
>>>> [ 5.525843] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.531571] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.537490] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 30
>>>> 73 bytes from PEB 107:108976, read only 3073 bytes, retry
>>>> [ 5.691121] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.696709] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.702426] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.708141] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 5.714103] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 30
>>>> 35 bytes from PEB 107:25144, read only 3035 bytes, retry
>>>> [ 20.523689] random: crng init done
>>>> [ 21.892130] ecc_sw_hamming_correct: uncorrectable ECC error
>>>> [ 21.897730] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 13
>>>> 94 bytes from PEB 116:75776, read only 1394 bytes, retry
>>>>
>>>> Most of the time, when the reading of the file fails, I just have to read it once more and it gets read without that error.
>>>
>>> It really looks like a regular bitflip happening "sometimes". Is this a
>>> board which already had a life? What are the usage counters (UBI should
>>> tell you this) compared to the official endurance of your chip (see the
>>> datasheet)?
>>
>> The board had a peacefull life:
>>
>> UBI reports "ubi0: max/mean erase counter: 49/20, WL threshold: 4096"
>
> Mmmh. Indeed.
>
>>
>> I have tried with half a dozen of boards and all have the issue.
>>
>>>
>>>> What am I supposed to do to avoid the ECC weakness warning at startup and to fix that ECC error issue ?
>>>
>>> I honestly don't think the errors come from the 5.1x kernels given the
>>> above logs. If you flash back your old 4.14 I am pretty sure you'll
>>> have the same errors at some point.
>>
>> I don't have any problem like that with 4.14 with any of the board.
>>
>> When booting a 4.14 kernel I don't get any problem on the same board.
>>
>
> If you can reliably show that when returning to a 4.14 kernel the ECC
> weakness disappears, then there is certainly something new. What driver
> are you using? Maybe you can do a bisection?
Using the GPIO driver, and the NAND chip is a HYNIX.
I can say that the ECC weakness doesn't exist until v5.5 included. The weakness appears with v5.6.
I have tried bisection between those two versions and I couldn't end up to a reliable result. The
closer the v5.5 you go, the more difficult it is to reproduce the issue.
So I looked at what was done around the places, and in fact that's mainly optimisation in the
powerpc code. It seems that the more powerpc is optimised, the more the problem occurs.
Looking at the GPIO nand driver, I saw that no-op gpio_nand_dosync() function. By adding a memory
barrier in that function, the ECC weakness disappeared completely.
Not sure what the final solution has to be.
Christophe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox