* [PATCH 2/2] tools/perf: Add perf tools support to expose instruction and data address registers as part of extended regs
From: Athira Rajeev @ 2021-06-20 14:46 UTC (permalink / raw)
To: mpe, acme, jolsa; +Cc: kjain, maddy, linuxppc-dev, rnsastry
In-Reply-To: <1624200360-1429-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Patch enables presenting of Sampled Instruction Address Register (SIAR)
and Sampled Data Address Register (SDAR) SPRs as part of extended regsiters
for perf tool. Add these SPR's to sample_reg_mask in the tool side (to use
with -I? option).
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 12 +++++++-----
tools/perf/arch/powerpc/include/perf_regs.h | 2 ++
tools/perf/arch/powerpc/util/perf_regs.c | 2 ++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
index 578b3ee..cf5eee5 100644
--- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -61,6 +61,8 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_PMC4,
PERF_REG_POWERPC_PMC5,
PERF_REG_POWERPC_PMC6,
+ PERF_REG_POWERPC_SDAR,
+ PERF_REG_POWERPC_SIAR,
/* Max regs without the extended regs */
PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
@@ -72,16 +74,16 @@ enum perf_event_powerpc_regs {
/*
* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300
- * includes 9 SPRS from MMCR0 to PMC6 excluding the
+ * includes 11 SPRS from MMCR0 to SIAR excluding the
* unsupported SPRS in PERF_EXCLUDE_REG_EXT_300.
*/
-#define PERF_REG_PMU_MASK_300 ((0xfffULL << PERF_REG_POWERPC_MMCR0) - PERF_EXCLUDE_REG_EXT_300)
+#define PERF_REG_PMU_MASK_300 ((0x3fffULL << PERF_REG_POWERPC_MMCR0) - PERF_EXCLUDE_REG_EXT_300)
/*
* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31
- * includes 12 SPRs from MMCR0 to PMC6.
+ * includes 14 SPRs from MMCR0 to SIAR.
*/
-#define PERF_REG_PMU_MASK_31 (0xfffULL << PERF_REG_POWERPC_MMCR0)
+#define PERF_REG_PMU_MASK_31 (0x3fffULL << PERF_REG_POWERPC_MMCR0)
-#define PERF_REG_EXTENDED_MAX (PERF_REG_POWERPC_PMC6 + 1)
+#define PERF_REG_EXTENDED_MAX (PERF_REG_POWERPC_SIAR + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index 04e5dc0..93339d1 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -77,6 +77,8 @@
[PERF_REG_POWERPC_PMC4] = "pmc4",
[PERF_REG_POWERPC_PMC5] = "pmc5",
[PERF_REG_POWERPC_PMC6] = "pmc6",
+ [PERF_REG_POWERPC_SDAR] = "sdar",
+ [PERF_REG_POWERPC_SIAR] = "siar",
};
static inline const char *__perf_reg_name(int id)
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
index 8116a25..8d07a78 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -74,6 +74,8 @@
SMPL_REG(pmc4, PERF_REG_POWERPC_PMC4),
SMPL_REG(pmc5, PERF_REG_POWERPC_PMC5),
SMPL_REG(pmc6, PERF_REG_POWERPC_PMC6),
+ SMPL_REG(sdar, PERF_REG_POWERPC_SDAR),
+ SMPL_REG(siar, PERF_REG_POWERPC_SIAR),
SMPL_REG_END
};
--
1.8.3.1
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS 7f030e9d57b8ff6025bde4162f42378e6081126a
From: kernel test robot @ 2021-06-20 12:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 7f030e9d57b8ff6025bde4162f42378e6081126a Automatic merge of 'fixes' into merge (2021-06-20 09:27)
elapsed time: 723m
configs tested: 114
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm allyesconfig
arm allmodconfig
arm64 allyesconfig
arm64 defconfig
sh se7206_defconfig
sh apsh4a3a_defconfig
sparc sparc64_defconfig
arm mv78xx0_defconfig
sh migor_defconfig
powerpc akebono_defconfig
powerpc klondike_defconfig
arm neponset_defconfig
powerpc icon_defconfig
powerpc mpc834x_itx_defconfig
arm at91_dt_defconfig
x86_64 allnoconfig
sh ul2_defconfig
arm sunxi_defconfig
arm imote2_defconfig
mips loongson2k_defconfig
mips malta_qemu_32r6_defconfig
sh secureedge5410_defconfig
powerpc cell_defconfig
powerpc maple_defconfig
arm stm32_defconfig
mips rs90_defconfig
arm assabet_defconfig
arm davinci_all_defconfig
arc haps_hs_defconfig
arm mvebu_v5_defconfig
sparc64 alldefconfig
sh sh7785lcr_32bit_defconfig
arm shannon_defconfig
powerpc tqm8548_defconfig
sh landisk_defconfig
powerpc ppc6xx_defconfig
mips decstation_r4k_defconfig
powerpc mpc8540_ads_defconfig
parisc generic-64bit_defconfig
m68k amcore_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
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-20210620
i386 randconfig-a002-20210620
i386 randconfig-a003-20210620
i386 randconfig-a006-20210620
i386 randconfig-a005-20210620
i386 randconfig-a004-20210620
x86_64 randconfig-a016-20210620
x86_64 randconfig-a015-20210620
x86_64 randconfig-a014-20210620
x86_64 randconfig-a012-20210620
x86_64 randconfig-a013-20210620
x86_64 randconfig-a011-20210620
i386 randconfig-a011-20210620
i386 randconfig-a014-20210620
i386 randconfig-a013-20210620
i386 randconfig-a015-20210620
i386 randconfig-a012-20210620
i386 randconfig-a016-20210620
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
x86_64 rhel-8.3-kselftests
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-20210620
x86_64 randconfig-a005-20210620
x86_64 randconfig-a004-20210620
x86_64 randconfig-a006-20210620
x86_64 randconfig-a002-20210620
x86_64 randconfig-a001-20210620
x86_64 randconfig-a003-20210620
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD REGRESSION 77ba1e2abc7474c5321cbf8d90366ec69150d0a2
From: kernel test robot @ 2021-06-20 12:38 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: 77ba1e2abc7474c5321cbf8d90366ec69150d0a2 powerpc: Enable KFENCE on BOOK3S/64
Error/Warning in current branch:
arch/powerpc/kernel/interrupt.c:36:20: error: unused function 'exit_must_hard_disable' [-Werror,-Wunused-function]
arch/powerpc/lib/code-patching.c:76:12: error: no previous prototype for 'poking_init' [-Werror=missing-prototypes]
arch/powerpc/lib/code-patching.c:76:12: warning: no previous prototype for 'poking_init' [-Wmissing-prototypes]
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- powerpc-mpc885_ads_defconfig
| `-- arch-powerpc-lib-code-patching.c:error:no-previous-prototype-for-poking_init
`-- powerpc64-randconfig-r011-20210620
`-- arch-powerpc-lib-code-patching.c:warning:no-previous-prototype-for-poking_init
clang_recent_errors
`-- powerpc-randconfig-r034-20210620
`-- arch-powerpc-kernel-interrupt.c:error:unused-function-exit_must_hard_disable-Werror-Wunused-function
elapsed time: 723m
configs tested: 108
configs skipped: 5
gcc tested configs:
arm64 defconfig
arm defconfig
arm64 allyesconfig
arm allyesconfig
arm allmodconfig
powerpc mpc885_ads_defconfig
sh j2_defconfig
sh se7712_defconfig
mips rb532_defconfig
xtensa common_defconfig
powerpc akebono_defconfig
powerpc klondike_defconfig
arm neponset_defconfig
powerpc icon_defconfig
powerpc obs600_defconfig
arm aspeed_g5_defconfig
powerpc skiroot_defconfig
arm imote2_defconfig
powerpc linkstation_defconfig
powerpc currituck_defconfig
microblaze mmu_defconfig
mips loongson2k_defconfig
mips malta_qemu_32r6_defconfig
sh secureedge5410_defconfig
powerpc cell_defconfig
sh urquell_defconfig
x86_64 allyesconfig
arm imx_v6_v7_defconfig
arm pxa168_defconfig
mips decstation_r4k_defconfig
arm davinci_all_defconfig
powerpc redwood_defconfig
ia64 bigsur_defconfig
powerpc mpc834x_mds_defconfig
mips nlm_xlp_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
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210620
i386 randconfig-a002-20210620
i386 randconfig-a003-20210620
i386 randconfig-a006-20210620
i386 randconfig-a005-20210620
i386 randconfig-a004-20210620
x86_64 randconfig-a012-20210620
x86_64 randconfig-a014-20210620
x86_64 randconfig-a013-20210620
x86_64 randconfig-a011-20210620
x86_64 randconfig-a016-20210620
x86_64 randconfig-a015-20210620
i386 randconfig-a011-20210620
i386 randconfig-a014-20210620
i386 randconfig-a013-20210620
i386 randconfig-a012-20210620
i386 randconfig-a015-20210620
i386 randconfig-a016-20210620
riscv nommu_k210_defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
um kunit_defconfig
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-20210620
x86_64 randconfig-a002-20210620
x86_64 randconfig-a001-20210620
x86_64 randconfig-a003-20210620
x86_64 randconfig-a004-20210620
x86_64 randconfig-a005-20210620
x86_64 randconfig-a006-20210620
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:fixes-test] BUILD SUCCESS 60b7ed54a41b550d50caf7f2418db4a7e75b5bdc
From: kernel test robot @ 2021-06-20 12:33 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test
branch HEAD: 60b7ed54a41b550d50caf7f2418db4a7e75b5bdc powerpc/perf: Fix crash in perf_instruction_pointer() when ppmu is not set
elapsed time: 721m
configs tested: 140
configs skipped: 19
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
powerpc mpc834x_itx_defconfig
mips loongson2k_defconfig
powerpc ep8248e_defconfig
sh espt_defconfig
mips ath79_defconfig
m68k bvme6000_defconfig
powerpc kmeter1_defconfig
powerpc mpc834x_mds_defconfig
powerpc akebono_defconfig
powerpc klondike_defconfig
arm neponset_defconfig
powerpc icon_defconfig
arc vdk_hs38_defconfig
powerpc acadia_defconfig
mips ci20_defconfig
sh lboxre2_defconfig
sh sh7763rdp_defconfig
mips maltaup_xpa_defconfig
arm palmz72_defconfig
sh hp6xx_defconfig
powerpc ep88xc_defconfig
powerpc mpc832x_rdb_defconfig
nios2 allyesconfig
mips rs90_defconfig
m68k m5272c3_defconfig
mips cobalt_defconfig
mips malta_qemu_32r6_defconfig
sh secureedge5410_defconfig
arm pxa3xx_defconfig
sh sh7724_generic_defconfig
powerpc tqm5200_defconfig
x86_64 allnoconfig
arm sunxi_defconfig
arm davinci_all_defconfig
arm h3600_defconfig
arm multi_v4t_defconfig
powerpc cell_defconfig
sh se7722_defconfig
h8300 defconfig
arm lpd270_defconfig
powerpc socrates_defconfig
m68k m5249evb_defconfig
arm cns3420vb_defconfig
mips decstation_64_defconfig
arm s3c2410_defconfig
s390 defconfig
powerpc bluestone_defconfig
sh urquell_defconfig
powerpc warp_defconfig
arm assabet_defconfig
mips loongson3_defconfig
sh titan_defconfig
ia64 tiger_defconfig
arm lubbock_defconfig
arm mps2_defconfig
sh magicpanelr2_defconfig
powerpc mpc8540_ads_defconfig
parisc generic-64bit_defconfig
m68k amcore_defconfig
arm corgi_defconfig
ia64 generic_defconfig
arm vexpress_defconfig
arm magician_defconfig
powerpc mpc512x_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nds32 defconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allmodconfig
parisc allyesconfig
s390 allyesconfig
sparc allyesconfig
sparc defconfig
i386 allyesconfig
i386 defconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20210620
i386 randconfig-a002-20210620
i386 randconfig-a003-20210620
i386 randconfig-a005-20210620
i386 randconfig-a004-20210620
i386 randconfig-a006-20210620
x86_64 randconfig-a016-20210620
x86_64 randconfig-a015-20210620
x86_64 randconfig-a014-20210620
x86_64 randconfig-a012-20210620
x86_64 randconfig-a013-20210620
x86_64 randconfig-a011-20210620
i386 randconfig-a016-20210620
i386 randconfig-a014-20210620
i386 randconfig-a015-20210620
i386 randconfig-a011-20210620
i386 randconfig-a013-20210620
i386 randconfig-a012-20210620
riscv nommu_k210_defconfig
riscv allnoconfig
riscv allmodconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
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-20210620
x86_64 randconfig-a005-20210620
x86_64 randconfig-a004-20210620
x86_64 randconfig-a006-20210620
x86_64 randconfig-a002-20210620
x86_64 randconfig-a001-20210620
x86_64 randconfig-a003-20210620
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v15 4/4] kasan: use MAX_PTRS_PER_* for early shadow tables
From: Andrey Konovalov @ 2021-06-20 11:17 UTC (permalink / raw)
To: Daniel Axtens
Cc: Marco Elver, aneesh.kumar, LKML, kasan-dev,
Linux Memory Management List, Andrew Morton, linuxppc-dev
In-Reply-To: <20210617093032.103097-5-dja@axtens.net>
On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> wrote:
>
> powerpc has a variable number of PTRS_PER_*, set at runtime based
> on the MMU that the kernel is booted under.
>
> This means the PTRS_PER_* are no longer constants, and therefore
> breaks the build. Switch to using MAX_PTRS_PER_*, which are constant.
>
> Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Suggested-by: Balbir Singh <bsingharora@gmail.com>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
> Reviewed-by: Marco Elver <elver@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
> include/linux/kasan.h | 6 +++---
> mm/kasan/init.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 768d7d342757..5310e217bd74 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -41,9 +41,9 @@ struct kunit_kasan_expectation {
> #endif
>
> extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
> -extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS];
> -extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
> -extern pud_t kasan_early_shadow_pud[PTRS_PER_PUD];
> +extern pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS];
> +extern pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD];
> +extern pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD];
> extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
>
> int kasan_populate_early_shadow(const void *shadow_start,
> diff --git a/mm/kasan/init.c b/mm/kasan/init.c
> index 348f31d15a97..cc64ed6858c6 100644
> --- a/mm/kasan/init.c
> +++ b/mm/kasan/init.c
> @@ -41,7 +41,7 @@ static inline bool kasan_p4d_table(pgd_t pgd)
> }
> #endif
> #if CONFIG_PGTABLE_LEVELS > 3
> -pud_t kasan_early_shadow_pud[PTRS_PER_PUD] __page_aligned_bss;
> +pud_t kasan_early_shadow_pud[MAX_PTRS_PER_PUD] __page_aligned_bss;
> static inline bool kasan_pud_table(p4d_t p4d)
> {
> return p4d_page(p4d) == virt_to_page(lm_alias(kasan_early_shadow_pud));
> @@ -53,7 +53,7 @@ static inline bool kasan_pud_table(p4d_t p4d)
> }
> #endif
> #if CONFIG_PGTABLE_LEVELS > 2
> -pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD] __page_aligned_bss;
> +pmd_t kasan_early_shadow_pmd[MAX_PTRS_PER_PMD] __page_aligned_bss;
> static inline bool kasan_pmd_table(pud_t pud)
> {
> return pud_page(pud) == virt_to_page(lm_alias(kasan_early_shadow_pmd));
> @@ -64,7 +64,7 @@ static inline bool kasan_pmd_table(pud_t pud)
> return false;
> }
> #endif
> -pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS]
> +pte_t kasan_early_shadow_pte[MAX_PTRS_PER_PTE + PTE_HWTABLE_PTRS]
> __page_aligned_bss;
>
> static inline bool kasan_pte_table(pmd_t pmd)
> --
> 2.30.2
>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
^ permalink raw reply
* Re: [PATCH v15 3/4] mm: define default MAX_PTRS_PER_* in include/pgtable.h
From: Andrey Konovalov @ 2021-06-20 11:17 UTC (permalink / raw)
To: Daniel Axtens
Cc: Marco Elver, aneesh.kumar, LKML, kasan-dev,
Linux Memory Management List, Andrew Morton, linuxppc-dev
In-Reply-To: <20210617093032.103097-4-dja@axtens.net>
On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> wrote:
>
> Commit c65e774fb3f6 ("x86/mm: Make PGDIR_SHIFT and PTRS_PER_P4D variable")
> made PTRS_PER_P4D variable on x86 and introduced MAX_PTRS_PER_P4D as a
> constant for cases which need a compile-time constant (e.g. fixed-size
> arrays).
>
> powerpc likewise has boot-time selectable MMU features which can cause
> other mm "constants" to vary. For KASAN, we have some static
> PTE/PMD/PUD/P4D arrays so we need compile-time maximums for all these
> constants. Extend the MAX_PTRS_PER_ idiom, and place default definitions
> in include/pgtable.h. These define MAX_PTRS_PER_x to be PTRS_PER_x unless
> an architecture has defined MAX_PTRS_PER_x in its arch headers.
>
> Clean up pgtable-nop4d.h and s390's MAX_PTRS_PER_P4D definitions while
> we're at it: both can just pick up the default now.
>
> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Reviewed-by: Marco Elver <elver@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
>
> ---
>
> s390 was compile tested only.
> ---
> arch/s390/include/asm/pgtable.h | 2 --
> include/asm-generic/pgtable-nop4d.h | 1 -
> include/linux/pgtable.h | 22 ++++++++++++++++++++++
> 3 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
> index 7c66ae5d7e32..cf05954ce013 100644
> --- a/arch/s390/include/asm/pgtable.h
> +++ b/arch/s390/include/asm/pgtable.h
> @@ -342,8 +342,6 @@ static inline int is_module_addr(void *addr)
> #define PTRS_PER_P4D _CRST_ENTRIES
> #define PTRS_PER_PGD _CRST_ENTRIES
>
> -#define MAX_PTRS_PER_P4D PTRS_PER_P4D
> -
> /*
> * Segment table and region3 table entry encoding
> * (R = read-only, I = invalid, y = young bit):
> diff --git a/include/asm-generic/pgtable-nop4d.h b/include/asm-generic/pgtable-nop4d.h
> index ce2cbb3c380f..2f6b1befb129 100644
> --- a/include/asm-generic/pgtable-nop4d.h
> +++ b/include/asm-generic/pgtable-nop4d.h
> @@ -9,7 +9,6 @@
> typedef struct { pgd_t pgd; } p4d_t;
>
> #define P4D_SHIFT PGDIR_SHIFT
> -#define MAX_PTRS_PER_P4D 1
> #define PTRS_PER_P4D 1
> #define P4D_SIZE (1UL << P4D_SHIFT)
> #define P4D_MASK (~(P4D_SIZE-1))
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 9e6f71265f72..69700e3e615f 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1625,4 +1625,26 @@ typedef unsigned int pgtbl_mod_mask;
> #define pte_leaf_size(x) PAGE_SIZE
> #endif
>
> +/*
> + * Some architectures have MMUs that are configurable or selectable at boot
> + * time. These lead to variable PTRS_PER_x. For statically allocated arrays it
> + * helps to have a static maximum value.
> + */
> +
> +#ifndef MAX_PTRS_PER_PTE
> +#define MAX_PTRS_PER_PTE PTRS_PER_PTE
> +#endif
> +
> +#ifndef MAX_PTRS_PER_PMD
> +#define MAX_PTRS_PER_PMD PTRS_PER_PMD
> +#endif
> +
> +#ifndef MAX_PTRS_PER_PUD
> +#define MAX_PTRS_PER_PUD PTRS_PER_PUD
> +#endif
> +
> +#ifndef MAX_PTRS_PER_P4D
> +#define MAX_PTRS_PER_P4D PTRS_PER_P4D
> +#endif
> +
> #endif /* _LINUX_PGTABLE_H */
> --
> 2.30.2
>
Acked-by: Andrey Konovalov <andreyknvl@gmail.com>
^ permalink raw reply
* Re: [PATCH v15 2/4] kasan: allow architectures to provide an outline readiness check
From: Andrey Konovalov @ 2021-06-20 11:16 UTC (permalink / raw)
To: Daniel Axtens
Cc: Marco Elver, aneesh.kumar, LKML, kasan-dev,
Linux Memory Management List, Andrew Morton, linuxppc-dev
In-Reply-To: <20210617093032.103097-3-dja@axtens.net>
On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> wrote:
>
> Allow architectures to define a kasan_arch_is_ready() hook that bails
> out of any function that's about to touch the shadow unless the arch
> says that it is ready for the memory to be accessed. This is fairly
> uninvasive and should have a negligible performance penalty.
>
> This will only work in outline mode, so an arch must specify
> ARCH_DISABLE_KASAN_INLINE if it requires this.
>
> Cc: Balbir Singh <bsingharora@gmail.com>
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Suggested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> Reviewed-by: Marco Elver <elver@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
>
> --
>
> Both previous RFCs for ppc64 - by 2 different people - have
> needed this trick! See:
> - https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
> - https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
>
> Build tested on arm64 with SW_TAGS and x86 with INLINE: the error fires
> if I add a kasan_arch_is_ready define.
> ---
> mm/kasan/common.c | 4 ++++
> mm/kasan/generic.c | 3 +++
> mm/kasan/kasan.h | 6 ++++++
> mm/kasan/shadow.c | 8 ++++++++
> 4 files changed, 21 insertions(+)
>
> 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;
Have you considered including these checks into the high-level
wrappers in include/linux/kasan.h? Would that work?
> +
> tag = get_tag(object);
> tagged_object = object;
> object = kasan_reset_tag(object);
> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> index 53cbf28859b5..c3f5ba7a294a 100644
> --- a/mm/kasan/generic.c
> +++ b/mm/kasan/generic.c
> @@ -163,6 +163,9 @@ static __always_inline bool check_region_inline(unsigned long addr,
> size_t size, bool write,
> unsigned long ret_ip)
> {
> + if (!kasan_arch_is_ready())
> + return true;
> +
> if (unlikely(size == 0))
> return true;
>
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 8f450bc28045..4dbc8def64f4 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -449,6 +449,12 @@ static inline void kasan_poison_last_granule(const void *address, size_t size) {
>
> #endif /* CONFIG_KASAN_GENERIC */
>
> +#ifndef kasan_arch_is_ready
> +static inline bool kasan_arch_is_ready(void) { return true; }
> +#elif !defined(CONFIG_KASAN_GENERIC) || !defined(CONFIG_KASAN_OUTLINE)
> +#error kasan_arch_is_ready only works in KASAN generic outline mode!
> +#endif
> +
> /*
> * Exported functions for interfaces called from assembly or from generated
> * code. Declarations here to avoid warning about missing declarations.
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 082ee5b6d9a1..3c7f7efe6f68 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -73,6 +73,10 @@ void kasan_poison(const void *addr, size_t size, u8 value, bool init)
> {
> void *shadow_start, *shadow_end;
>
> + /* Don't touch the shadow memory if arch isn't ready */
> + if (!kasan_arch_is_ready())
> + return;
> +
> /*
> * Perform shadow offset calculation based on untagged address, as
> * some of the callers (e.g. kasan_poison_object_data) pass tagged
> @@ -99,6 +103,10 @@ EXPORT_SYMBOL(kasan_poison);
> #ifdef CONFIG_KASAN_GENERIC
> void kasan_poison_last_granule(const void *addr, size_t size)
> {
> + /* Don't touch the shadow memory if arch isn't ready */
> + if (!kasan_arch_is_ready())
> + return;
> +
> if (size & KASAN_GRANULE_MASK) {
> u8 *shadow = (u8 *)kasan_mem_to_shadow(addr + size);
> *shadow = size & KASAN_GRANULE_MASK;
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH v15 1/4] kasan: allow an architecture to disable inline instrumentation
From: Andrey Konovalov @ 2021-06-20 11:15 UTC (permalink / raw)
To: Daniel Axtens
Cc: Marco Elver, aneesh.kumar, LKML, kasan-dev,
Linux Memory Management List, Andrew Morton, linuxppc-dev
In-Reply-To: <20210617093032.103097-2-dja@axtens.net>
On Thu, Jun 17, 2021 at 12:30 PM Daniel Axtens <dja@axtens.net> wrote:
>
> For annoying architectural reasons, it's very difficult to support inline
> instrumentation on powerpc64.*
>
> Add a Kconfig flag to allow an arch to disable inline. (It's a bit
> annoying to be 'backwards', but I'm not aware of any way to have
> an arch force a symbol to be 'n', rather than 'y'.)
>
> We also disable stack instrumentation in this case as it does things that
> are functionally equivalent to inline instrumentation, namely adding
> code that touches the shadow directly without going through a C helper.
>
> * on ppc64 atm, the shadow lives in virtual memory and isn't accessible in
> real mode. However, before we turn on virtual memory, we parse the device
> tree to determine which platform and MMU we're running under. That calls
> generic DT code, which is instrumented. Inline instrumentation in DT would
> unconditionally attempt to touch the shadow region, which we won't have
> set up yet, and would crash. We can make outline mode wait for the arch to
> be ready, but we can't change what the compiler inserts for inline mode.
>
> Reviewed-by: Marco Elver <elver@google.com>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
> lib/Kconfig.kasan | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
> index cffc2ebbf185..cb5e02d09e11 100644
> --- a/lib/Kconfig.kasan
> +++ b/lib/Kconfig.kasan
> @@ -12,6 +12,15 @@ config HAVE_ARCH_KASAN_HW_TAGS
> config HAVE_ARCH_KASAN_VMALLOC
> bool
>
> +config ARCH_DISABLE_KASAN_INLINE
> + bool
> + help
> + Sometimes an architecture might not be able to support inline
> + instrumentation but might be able to support outline instrumentation.
> + This option allows an architecture to prevent inline and stack
> + instrumentation from being enabled.
This seems too wordy.
How about: "An architecture might not support inline instrumentation.
When this option is selected, inline and stack instrumentation are
disabled."
> +
> +
Drop the extra empty line.
> config CC_HAS_KASAN_GENERIC
> def_bool $(cc-option, -fsanitize=kernel-address)
>
> @@ -130,6 +139,7 @@ config KASAN_OUTLINE
>
> config KASAN_INLINE
> bool "Inline instrumentation"
> + depends on !ARCH_DISABLE_KASAN_INLINE
> help
> Compiler directly inserts code checking shadow memory before
> memory accesses. This is faster than outline (in some workloads
> @@ -141,6 +151,7 @@ endchoice
> config KASAN_STACK
> bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
> depends on KASAN_GENERIC || KASAN_SW_TAGS
> + depends on !ARCH_DISABLE_KASAN_INLINE
> default y if CC_IS_GCC
> help
> The LLVM stack address sanitizer has a know problem that
> @@ -154,6 +165,9 @@ config KASAN_STACK
> but clang users can still enable it for builds without
> CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe
> to use and enabled by default.
> + If the architecture disables inline instrumentation, this is
this => stack instrumentation
> + also disabled as it adds inline-style instrumentation that
> + is run unconditionally.
>
> config KASAN_SW_TAGS_IDENTIFY
> bool "Enable memory corruption identification"
> --
> 2.30.2
>
^ permalink raw reply
* Re: [PATCH v2 6/9] powerpc/microwatt: Add support for hardware random number generator
From: Nicholas Piggin @ 2021-06-20 8:19 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20210619143640.GX5077@gate.crashing.org>
Excerpts from Segher Boessenkool's message of June 20, 2021 12:36 am:
> On Sat, Jun 19, 2021 at 01:08:51PM +1000, Nicholas Piggin wrote:
>> Excerpts from Paul Mackerras's message of June 18, 2021 1:47 pm:
>> > Microwatt's hardware RNG is accessed using the DARN instruction.
>>
>> I think we're getting a platforms/book3s soon with the VAS patches,
>> might be a place to add the get_random_darn function.
>>
>> Huh, DARN is unprivileged right?
>
> It is, that's the whole point: to make it very very cheap for user
> software it has to be an unprivileged instruction.
Right, I was just doing a double-take. In that case we should enable it
in the pseries random number code as well, so it really would be a
generic isa 3.0 function that all (microwatt, powernv, pseries) could
use AFAIKS.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation
From: Nicholas Piggin @ 2021-06-20 2:10 UTC (permalink / raw)
To: Andy Lutomirski, Mathieu Desnoyers
Cc: Will Deacon, linux-mm, Peter Zijlstra (Intel),
the arch/x86 maintainers, Linux Kernel Mailing List, stable,
Dave Hansen, Paul Mackerras, Catalin Marinas, Andrew Morton,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <2f9e52eb-0105-4bc6-a903-f4ecbfc9b999@www.fastmail.com>
Excerpts from Andy Lutomirski's message of June 20, 2021 1:50 am:
>
>
> On Fri, Jun 18, 2021, at 11:02 PM, Nicholas Piggin wrote:
>> Excerpts from Mathieu Desnoyers's message of June 19, 2021 6:09 am:
>> > ----- On Jun 18, 2021, at 3:58 PM, Andy Lutomirski luto@kernel.org wrote:
>> >
>> >> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
>> >>> ----- On Jun 17, 2021, at 8:12 PM, Andy Lutomirski luto@kernel.org wrote:
>> >>>
>> >>> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>> >>> >
>> >>> >> Please change back this #ifndef / #else / #endif within function for
>> >>> >>
>> >>> >> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) {
>> >>> >> ...
>> >>> >> } else {
>> >>> >> ...
>> >>> >> }
>> >>> >>
>> >>> >> I don't think mixing up preprocessor and code logic makes it more readable.
>> >>> >
>> >>> > I agree, but I don't know how to make the result work well.
>> >>> > membarrier_sync_core_before_usermode() isn't defined in the !IS_ENABLED
>> >>> > case, so either I need to fake up a definition or use #ifdef.
>> >>> >
>> >>> > If I faked up a definition, I would want to assert, at build time, that
>> >>> > it isn't called. I don't think we can do:
>> >>> >
>> >>> > static void membarrier_sync_core_before_usermode()
>> >>> > {
>> >>> > BUILD_BUG_IF_REACHABLE();
>> >>> > }
>> >>>
>> >>> Let's look at the context here:
>> >>>
>> >>> static void ipi_sync_core(void *info)
>> >>> {
>> >>> [....]
>> >>> membarrier_sync_core_before_usermode()
>> >>> }
>> >>>
>> >>> ^ this can be within #ifdef / #endif
>> >>>
>> >>> static int membarrier_private_expedited(int flags, int cpu_id)
>> >>> [...]
>> >>> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE))
>> >>> return -EINVAL;
>> >>> if (!(atomic_read(&mm->membarrier_state) &
>> >>> MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE_READY))
>> >>> return -EPERM;
>> >>> ipi_func = ipi_sync_core;
>> >>>
>> >>> All we need to make the line above work is to define an empty ipi_sync_core
>> >>> function in the #else case after the ipi_sync_core() function definition.
>> >>>
>> >>> Or am I missing your point ?
>> >>
>> >> Maybe?
>> >>
>> >> My objection is that an empty ipi_sync_core is a lie — it doesn’t sync the core.
>> >> I would be fine with that if I could have the compiler statically verify that
>> >> it’s not called, but I’m uncomfortable having it there if the implementation is
>> >> actively incorrect.
>> >
>> > I see. Another approach would be to implement a "setter" function to populate
>> > "ipi_func". That setter function would return -EINVAL in its #ifndef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
>> > implementation.
>>
>> I still don't get the problem with my suggestion. Sure the
>> ipi is a "lie", but it doesn't get used. That's how a lot of
>> ifdef folding works out. E.g.,
>>
>> diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
>> index b5add64d9698..54cb32d064af 100644
>> --- a/kernel/sched/membarrier.c
>> +++ b/kernel/sched/membarrier.c
>> @@ -5,6 +5,15 @@
>> * membarrier system call
>> */
>> #include "sched.h"
>> +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
>> +#include <asm/sync_core.h>
>> +#else
>> +static inline void membarrier_sync_core_before_usermode(void)
>> +{
>> + compiletime_assert(0, "architecture does not implement
>> membarrier_sync_core_before_usermode");
>> +}
>> +
>
> With the assert there, I’m fine with this. Let me see if the result builds.
It had better, because compiletime_assert already relies on a similar
level of code elimination to work.
I think it's fine to use for now, but it may not be quite the the
logically correct primitive if we want to be really clean, because a
valid compiletime_assert implementation should be able to fire even for
code that is never linked. We would want something like to be clean
IMO:
#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
#include <asm/sync_core.h>
#else
extern void membarrier_sync_core_before_usermode(void) __compiletime_error("architecture does not implement membarrier_sync_core_before_usermode");
#endif
However that does not have the ifdef for optimising compile so AFAIKS it
could break with a false positive in some cases.
Something like compiletime_assert_not_called("msg") that either compiles
to a noop or a __compiletime_error depending on __OPTIMIZE__ would be
the way to go IMO. I don't know if anything exists that fits, but it's
certainly not a unique thing in the kernel so I may not be looking hard
enough.
Thanks,
Nick
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.13-6 tag
From: Michael Ellerman @ 2021-06-19 23:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: atrajeev, linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.13:
The following changes since commit 59cc84c802eb923805e7bba425976a3df5ce35d8:
Revert "powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs" (2021-06-01 11:17:08 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.13-6
for you to fetch changes up to 60b7ed54a41b550d50caf7f2418db4a7e75b5bdc:
powerpc/perf: Fix crash in perf_instruction_pointer() when ppmu is not set (2021-06-18 16:30:36 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.13 #6
Fix initrd corruption caused by our recent change to use relative jump labels.
Fix a crash using perf record on systems without a hardware PMU backend.
Rework our 64-bit signal handling slighty to make it more closely match the old behaviour,
after the recent change to use unsafe user accessors.
Thanks to: Anastasia Kovaleva, Athira Rajeev, Christophe Leroy, Daniel Axtens, Greg Kurz,
Roman Bolshakov.
- ------------------------------------------------------------------
Athira Rajeev (1):
powerpc/perf: Fix crash in perf_instruction_pointer() when ppmu is not set
Christophe Leroy (1):
powerpc/mem: Add back missing header to fix 'no previous prototype' error
Michael Ellerman (2):
powerpc/signal64: Copy siginfo before changing regs->nip
powerpc: Fix initrd corruption with relative jump labels
arch/powerpc/include/asm/jump_label.h | 2 +-
arch/powerpc/kernel/signal_64.c | 9 ++++-----
arch/powerpc/mm/mem.c | 1 +
arch/powerpc/perf/core-book3s.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmDOf4MACgkQUevqPMjh
pYCWZQ/+IFYW1st6xlM1jBDlLSItSn234dqOmvlihIo+9lCR82l72H4E4EWIj7A+
3GGzMllEdDcGooEF1jg+7+zUlx8i1WNlRCF4RNszGzpipiDWGPlxW2t5FqNeQRQ7
YyooMzrgPYlRxGHnG/KHfGiPJxxLj4ZsyRhWfoS6cY1EbS/YOX8SDX1Xz2qQu/Jr
qRzZvSZKkBpVdvcxEYcn7WSauDpqtZ9keWHdP8e6WRd/Bceu4nyxlxOI0z+pBUsr
3IhWzQexznJwCGClQBbaXg/uPmUDtEjx+LzhU0jTmSMLxVI+UFPVDIbco6bMX7AE
EevcU35aDLu8tclNd3IAA9Au/EZPUe8kMNUPmBncFAID4ek+gybRJuGO9b9XEJ1r
AZFFCb2rRugBvOeNtb5y3u9XNR0Ct0S2lsZygSOkCQ6R3Sf2yoVgP0M49PbFvEEO
fSVLnAMEWQDWfaLjYxFXp2S3vddyLw8G36lBzJo74Y/cRuz10g/87oWpIlFq5tqK
aMXTroINmErOv1XVALqix1ScrLeBnPlL2nH0gBSZ96W0A196kFjWkKaGsQFwXMEH
X2Om1rKYiC3/vKrLXRYcxSZcoRg7/a1es7ftVSv5DQAPGRGWDrplCJh70x5JW2Js
kA6IB2K8+Ehf3F0a7O+i5q5t1oTvOvR+wIEl2TpJdx5aMVGkBt0=
=CmCH
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v3] lockdown, selinux: fix wrong subject in some SELinux lockdown checks
From: Thomas Gleixner @ 2021-06-19 17:00 UTC (permalink / raw)
To: Ondrej Mosnacek, linux-security-module, James Morris
Cc: linux-efi, linux-pci, linux-cxl, Steffen Klassert, Paul Moore,
x86, linux-acpi, Ingo Molnar, linux-serial, linux-pm, selinux,
Steven Rostedt, linux-fsdevel, Herbert Xu, netdev,
Stephen Smalley, kexec, linux-kernel, Casey Schaufler, bpf,
linuxppc-dev, David S . Miller
In-Reply-To: <20210616085118.1141101-1-omosnace@redhat.com>
On Wed, Jun 16 2021 at 10:51, Ondrej Mosnacek wrote:
> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index bda73cb7a044..c43a13241ae8 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -116,7 +116,7 @@ static void do_test_bulk_ioremapping(void)
> static int __init init(void)
> {
> unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
> - int ret = security_locked_down(LOCKDOWN_MMIOTRACE);
> + int ret = security_locked_down(current_cred(), LOCKDOWN_MMIOTRACE);
I have no real objection to those patches, but it strikes me odd that
out of the 62 changed places 58 have 'current_cred()' and 4 have NULL as
argument.
I can't see why this would ever end up with anything else than
current_cred() or NULL and NULL being the 'special' case. So why not
having security_locked_down_no_cred() and make current_cred() implicit
for security_locked_down() which avoids most of the churn and just makes
the special cases special. I might be missing something though.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation
From: Andy Lutomirski @ 2021-06-19 15:50 UTC (permalink / raw)
To: Nicholas Piggin, Mathieu Desnoyers
Cc: Will Deacon, linux-mm, Peter Zijlstra (Intel),
the arch/x86 maintainers, Linux Kernel Mailing List, stable,
Dave Hansen, Paul Mackerras, Catalin Marinas, Andrew Morton,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1624080924.z61zvzi4cq.astroid@bobo.none>
On Fri, Jun 18, 2021, at 11:02 PM, Nicholas Piggin wrote:
> Excerpts from Mathieu Desnoyers's message of June 19, 2021 6:09 am:
> > ----- On Jun 18, 2021, at 3:58 PM, Andy Lutomirski luto@kernel.org wrote:
> >
> >> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
> >>> ----- On Jun 17, 2021, at 8:12 PM, Andy Lutomirski luto@kernel.org wrote:
> >>>
> >>> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
> >>> >
> >>> >> Please change back this #ifndef / #else / #endif within function for
> >>> >>
> >>> >> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) {
> >>> >> ...
> >>> >> } else {
> >>> >> ...
> >>> >> }
> >>> >>
> >>> >> I don't think mixing up preprocessor and code logic makes it more readable.
> >>> >
> >>> > I agree, but I don't know how to make the result work well.
> >>> > membarrier_sync_core_before_usermode() isn't defined in the !IS_ENABLED
> >>> > case, so either I need to fake up a definition or use #ifdef.
> >>> >
> >>> > If I faked up a definition, I would want to assert, at build time, that
> >>> > it isn't called. I don't think we can do:
> >>> >
> >>> > static void membarrier_sync_core_before_usermode()
> >>> > {
> >>> > BUILD_BUG_IF_REACHABLE();
> >>> > }
> >>>
> >>> Let's look at the context here:
> >>>
> >>> static void ipi_sync_core(void *info)
> >>> {
> >>> [....]
> >>> membarrier_sync_core_before_usermode()
> >>> }
> >>>
> >>> ^ this can be within #ifdef / #endif
> >>>
> >>> static int membarrier_private_expedited(int flags, int cpu_id)
> >>> [...]
> >>> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE))
> >>> return -EINVAL;
> >>> if (!(atomic_read(&mm->membarrier_state) &
> >>> MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE_READY))
> >>> return -EPERM;
> >>> ipi_func = ipi_sync_core;
> >>>
> >>> All we need to make the line above work is to define an empty ipi_sync_core
> >>> function in the #else case after the ipi_sync_core() function definition.
> >>>
> >>> Or am I missing your point ?
> >>
> >> Maybe?
> >>
> >> My objection is that an empty ipi_sync_core is a lie — it doesn’t sync the core.
> >> I would be fine with that if I could have the compiler statically verify that
> >> it’s not called, but I’m uncomfortable having it there if the implementation is
> >> actively incorrect.
> >
> > I see. Another approach would be to implement a "setter" function to populate
> > "ipi_func". That setter function would return -EINVAL in its #ifndef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
> > implementation.
>
> I still don't get the problem with my suggestion. Sure the
> ipi is a "lie", but it doesn't get used. That's how a lot of
> ifdef folding works out. E.g.,
>
> diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
> index b5add64d9698..54cb32d064af 100644
> --- a/kernel/sched/membarrier.c
> +++ b/kernel/sched/membarrier.c
> @@ -5,6 +5,15 @@
> * membarrier system call
> */
> #include "sched.h"
> +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
> +#include <asm/sync_core.h>
> +#else
> +static inline void membarrier_sync_core_before_usermode(void)
> +{
> + compiletime_assert(0, "architecture does not implement
> membarrier_sync_core_before_usermode");
> +}
> +
With the assert there, I’m fine with this. Let me see if the result builds.
> +#endif
>
> /*
> * For documentation purposes, here are some membarrier ordering
>
^ permalink raw reply
* Re: [PATCH for 4.16 v7 02/11] powerpc: membarrier: Skip memory barrier in switch_mm()
From: Segher Boessenkool @ 2021-06-19 15:02 UTC (permalink / raw)
To: Christophe Leroy
Cc: maged michael, Peter Zijlstra, Dave Watson, Will Deacon,
Russell King, ARM Linux, David Sehr, Paul Mackerras,
H. Peter Anvin, linux-arch, x86, Andrew Hunter, Greg Hackmann,
Ingo Molnar, Alan Stern, Paul, Andrea Parri, Avi Kivity,
Boqun Feng, linuxppc-dev, Nicholas Piggin, Mathieu Desnoyers,
Alexander Viro, Andy Lutomirski, Thomas Gleixner, linux-api,
linux-kernel, Linus Torvalds
In-Reply-To: <4d2026cc-28e1-7781-fc95-e6160bd8db86@csgroup.eu>
On Sat, Jun 19, 2021 at 11:35:34AM +0200, Christophe Leroy wrote:
>
>
> Le 18/06/2021 à 19:26, Mathieu Desnoyers a écrit :
> >----- On Jun 18, 2021, at 1:13 PM, Christophe Leroy
> >christophe.leroy@csgroup.eu wrote:
> >[...]
> >>
> >>I don't understand all that complexity to just replace a simple
> >>'smp_mb__after_unlock_lock()'.
> >>
> >>#define smp_mb__after_unlock_lock() smp_mb()
> >>#define smp_mb() barrier()
> >># define barrier() __asm__ __volatile__("": : :"memory")
> >>
> >>
> >>Am I missing some subtility ?
> >
> >On powerpc CONFIG_SMP, smp_mb() is actually defined as:
> >
> >#define smp_mb() __smp_mb()
> >#define __smp_mb() mb()
> >#define mb() __asm__ __volatile__ ("sync" : : : "memory")
> >
> >So the original motivation here was to skip a "sync" instruction whenever
> >switching between threads which are part of the same process. But based on
> >recent discussions, I suspect my implementation may be inaccurately doing
> >so though.
> >
>
> I see.
>
> Then, if you think a 'sync' is a concern, shouldn't we try and remove the
> forest of 'sync' in the I/O accessors ?
>
> I can't really understand why we need all those 'sync' and 'isync' and
> 'twi' around the accesses whereas I/O memory is usually mapped as 'Guarded'
> so memory access ordering is already garantied.
>
> I'm sure we'll save a lot with that.
The point of the twi in the I/O accessors was to make things easier to
debug if the accesses fail: for the twi insn to complete the load will
have to have completed as well. On a correctly working system you never
should need this (until something fails ;-) )
Without the twi you might need to enforce ordering in some cases still.
The twi is a very heavy hammer, but some of that that gives us is no
doubt actually needed.
Segher
^ permalink raw reply
* Re: [PATCH v2 0/9] powerpc: Add support for Microwatt soft-core
From: Segher Boessenkool @ 2021-06-19 14:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <YMwWPcsaWzMlDPqQ@thinks.paulus.ozlabs.org>
On Fri, Jun 18, 2021 at 01:42:53PM +1000, Paul Mackerras wrote:
> This series of patches adds support for the Microwatt soft-core.
> Microwatt is an open-source 64-bit Power ISA processor written in VHDL
> which targets medium-sized FPGAs such as the Xilinx Artix-7 or the
> Lattice ECP5. Microwatt currently implements the scalar fixed plus
> floating-point subset of Power ISA v3.0B plus the radix MMU, but not
> logical partitioning (i.e. it does not have hypervisor mode or nested
> radix translation).
For the whole series:
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
I didn't see anything in this revision that would prevent it from
being included upstream (that HV=1 thing should be fixed sooner rather
than later, but that is not a kernel problem). Looks in great state :-)
Segher
^ permalink raw reply
* Re: [PATCH v2 6/9] powerpc/microwatt: Add support for hardware random number generator
From: Segher Boessenkool @ 2021-06-19 14:36 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <1624071936.oqwaldrt74.astroid@bobo.none>
On Sat, Jun 19, 2021 at 01:08:51PM +1000, Nicholas Piggin wrote:
> Excerpts from Paul Mackerras's message of June 18, 2021 1:47 pm:
> > Microwatt's hardware RNG is accessed using the DARN instruction.
>
> I think we're getting a platforms/book3s soon with the VAS patches,
> might be a place to add the get_random_darn function.
>
> Huh, DARN is unprivileged right?
It is, that's the whole point: to make it very very cheap for user
software it has to be an unprivileged instruction.
Segher
^ permalink raw reply
* Re: [PATCH v2 2/9] powerpc: Add Microwatt device tree
From: Segher Boessenkool @ 2021-06-19 14:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <YMwWkPcXlGDSQ9Q3@thinks.paulus.ozlabs.org>
On Fri, Jun 18, 2021 at 01:44:16PM +1000, Paul Mackerras wrote:
> Microwatt currently runs with MSR[HV] = 0,
That isn't compliant though? If your implementation does not have LPAR
it must set MSR[HV]=1 always.
Segher
^ permalink raw reply
* Re: [PATCH for 4.16 v7 02/11] powerpc: membarrier: Skip memory barrier in switch_mm()
From: Christophe Leroy @ 2021-06-19 9:35 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: maged michael, Peter Zijlstra, Dave Watson, Will Deacon,
Andrew Hunter, David Sehr, Paul Mackerras, H. Peter Anvin,
linux-arch, x86, Russell King, ARM Linux, Greg Hackmann,
Linus Torvalds, Ingo Molnar, Alan Stern, Paul, Andrea Parri,
Avi Kivity, Boqun Feng, Nicholas Piggin, Alexander Viro,
Andy Lutomirski, Thomas Gleixner, linux-api, linux-kernel,
linuxppc-dev
In-Reply-To: <2077369633.12794.1624037192994.JavaMail.zimbra@efficios.com>
Le 18/06/2021 à 19:26, Mathieu Desnoyers a écrit :
> ----- On Jun 18, 2021, at 1:13 PM, Christophe Leroy christophe.leroy@csgroup.eu wrote:
> [...]
>>
>> I don't understand all that complexity to just replace a simple
>> 'smp_mb__after_unlock_lock()'.
>>
>> #define smp_mb__after_unlock_lock() smp_mb()
>> #define smp_mb() barrier()
>> # define barrier() __asm__ __volatile__("": : :"memory")
>>
>>
>> Am I missing some subtility ?
>
> On powerpc CONFIG_SMP, smp_mb() is actually defined as:
>
> #define smp_mb() __smp_mb()
> #define __smp_mb() mb()
> #define mb() __asm__ __volatile__ ("sync" : : : "memory")
>
> So the original motivation here was to skip a "sync" instruction whenever
> switching between threads which are part of the same process. But based on
> recent discussions, I suspect my implementation may be inaccurately doing
> so though.
>
I see.
Then, if you think a 'sync' is a concern, shouldn't we try and remove the forest of 'sync' in the
I/O accessors ?
I can't really understand why we need all those 'sync' and 'isync' and 'twi' around the accesses
whereas I/O memory is usually mapped as 'Guarded' so memory access ordering is already garantied.
I'm sure we'll save a lot with that.
Christophe
^ permalink raw reply
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-06-19 8:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #33 from Erhard F. (erhard_f@mailbox.org) ---
I can tell you in the next few weeks, as soon as my G4 MDD gets its' overhaul
with the serviced PSU.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 11143] [PATCH]unconditional linker option arch/powerpc/lib/crtsavres.o causes external module buildfailure
From: bugzilla-daemon @ 2021-06-19 6:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-11143-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=11143
Christophe Leroy (christophe.leroy@csgroup.eu) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christophe.leroy@csgroup.eu
--- Comment #19 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Seems like commit efe0160cfd40a99c052a00e174787c1f4158a9cd removes it for
binutils >= 2.25
Can you check it works for you now ?
I so, maybe the simplest solution is to wait until binutils minimum version is
at least 2.25. For the time being the minimum is 2.23
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 209277] powerpc: obsolete driver: Marvell MV64X60 MPSC
From: bugzilla-daemon @ 2021-06-19 6:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-209277-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=209277
--- Comment #4 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
The watchdog patch is flagged 'accepted' in patchwork, should go into 5.14
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 209277] powerpc: obsolete driver: Marvell MV64X60 MPSC
From: bugzilla-daemon @ 2021-06-19 6:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-209277-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=209277
Christophe Leroy (christophe.leroy@csgroup.eu) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christophe.leroy@csgroup.eu
--- Comment #3 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
https://github.com/linuxppc/linux/commit/a329ddd472fa2af0c19a73b8658898ae7fd658ad
https://github.com/linuxppc/linux/commit/600cc3c9c62defd920da07bc585eb739247bb732
https://patchwork.kernel.org/project/linux-watchdog/patch/9c2952bcfaec3b1789909eaa36bbce2afbfab7ab.1616085654.git.christophe.leroy@csgroup.eu/
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 205099] KASAN hit at raid6_pq: BUG: Unable to handle kernel data access at 0x00f0fd0d
From: bugzilla-daemon @ 2021-06-19 6:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-205099-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #32 from Christophe Leroy (christophe.leroy@csgroup.eu) ---
Is this problem still there with 5.13 ?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation
From: Nicholas Piggin @ 2021-06-19 6:02 UTC (permalink / raw)
To: Andy Lutomirski, Mathieu Desnoyers
Cc: Will Deacon, linux-mm, Peter Zijlstra, x86, linux-kernel, stable,
Dave Hansen, Paul Mackerras, Catalin Marinas, Andrew Morton,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <639092151.13266.1624046981084.JavaMail.zimbra@efficios.com>
Excerpts from Mathieu Desnoyers's message of June 19, 2021 6:09 am:
> ----- On Jun 18, 2021, at 3:58 PM, Andy Lutomirski luto@kernel.org wrote:
>
>> On Fri, Jun 18, 2021, at 9:31 AM, Mathieu Desnoyers wrote:
>>> ----- On Jun 17, 2021, at 8:12 PM, Andy Lutomirski luto@kernel.org wrote:
>>>
>>> > On 6/17/21 7:47 AM, Mathieu Desnoyers wrote:
>>> >
>>> >> Please change back this #ifndef / #else / #endif within function for
>>> >>
>>> >> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE)) {
>>> >> ...
>>> >> } else {
>>> >> ...
>>> >> }
>>> >>
>>> >> I don't think mixing up preprocessor and code logic makes it more readable.
>>> >
>>> > I agree, but I don't know how to make the result work well.
>>> > membarrier_sync_core_before_usermode() isn't defined in the !IS_ENABLED
>>> > case, so either I need to fake up a definition or use #ifdef.
>>> >
>>> > If I faked up a definition, I would want to assert, at build time, that
>>> > it isn't called. I don't think we can do:
>>> >
>>> > static void membarrier_sync_core_before_usermode()
>>> > {
>>> > BUILD_BUG_IF_REACHABLE();
>>> > }
>>>
>>> Let's look at the context here:
>>>
>>> static void ipi_sync_core(void *info)
>>> {
>>> [....]
>>> membarrier_sync_core_before_usermode()
>>> }
>>>
>>> ^ this can be within #ifdef / #endif
>>>
>>> static int membarrier_private_expedited(int flags, int cpu_id)
>>> [...]
>>> if (!IS_ENABLED(CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE))
>>> return -EINVAL;
>>> if (!(atomic_read(&mm->membarrier_state) &
>>> MEMBARRIER_STATE_PRIVATE_EXPEDITED_SYNC_CORE_READY))
>>> return -EPERM;
>>> ipi_func = ipi_sync_core;
>>>
>>> All we need to make the line above work is to define an empty ipi_sync_core
>>> function in the #else case after the ipi_sync_core() function definition.
>>>
>>> Or am I missing your point ?
>>
>> Maybe?
>>
>> My objection is that an empty ipi_sync_core is a lie — it doesn’t sync the core.
>> I would be fine with that if I could have the compiler statically verify that
>> it’s not called, but I’m uncomfortable having it there if the implementation is
>> actively incorrect.
>
> I see. Another approach would be to implement a "setter" function to populate
> "ipi_func". That setter function would return -EINVAL in its #ifndef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
> implementation.
I still don't get the problem with my suggestion. Sure the
ipi is a "lie", but it doesn't get used. That's how a lot of
ifdef folding works out. E.g.,
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index b5add64d9698..54cb32d064af 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -5,6 +5,15 @@
* membarrier system call
*/
#include "sched.h"
+#ifdef CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE
+#include <asm/sync_core.h>
+#else
+static inline void membarrier_sync_core_before_usermode(void)
+{
+ compiletime_assert(0, "architecture does not implement membarrier_sync_core_before_usermode");
+}
+
+#endif
/*
* For documentation purposes, here are some membarrier ordering
^ permalink raw reply related
* Re: [PATCH v13 00/12] Restricted DMA
From: Claire Chang @ 2021-06-19 3:43 UTC (permalink / raw)
To: Rob Herring, mpe, Joerg Roedel, Will Deacon, Frank Rowand,
Konrad Rzeszutek Wilk, boris.ostrovsky, jgross, Christoph Hellwig,
Marek Szyprowski
Cc: heikki.krogerus, thomas.hellstrom, peterz, joonas.lahtinen,
dri-devel, chris, grant.likely, paulus, mingo, Jianxiong Gao,
Stefano Stabellini, Saravana Kannan, xypron.glpk,
Rafael J . Wysocki, Bartosz Golaszewski, bskeggs, linux-pci,
xen-devel, Thierry Reding, intel-gfx, matthew.auld,
linux-devicetree, Daniel Vetter, airlied, maarten.lankhorst,
linuxppc-dev, jani.nikula, Nicolas Boichat, rodrigo.vivi,
Bjorn Helgaas, Dan Williams, Andy Shevchenko, Greg KH,
Randy Dunlap, lkml, Tomasz Figa, list@263.net:IOMMU DRIVERS,
Jim Quinlan, Robin Murphy, bauerman
In-Reply-To: <CALiNf2_qF7OY0LHToNYx0E79BWMt2n7=nepPPLf+7YV3=KFEyw@mail.gmail.com>
v14: https://lore.kernel.org/patchwork/cover/1448954/
^ 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