* Re: [PATCH 1/5] selftests/powerpc: Add header files for GZIP engine test
From: Daniel Axtens @ 2020-03-18 3:48 UTC (permalink / raw)
To: Raphael Moreira Zinsly, linuxppc-dev, linux-crypto
Cc: abali, haren, herbert, Raphael Moreira Zinsly
In-Reply-To: <20200316180714.18631-2-rzinsly@linux.ibm.com>
Hi,
This is throwing a number of snowpatch warnings, as well as a whitespace
warning when I apply it. Please could you check the warnings at
https://patchwork.ozlabs.org/patch/1255779/
It looks like the rest of the series also throws some warnings - please
check those also.
Kind regards,
Daniel
Raphael Moreira Zinsly <rzinsly@linux.ibm.com> writes:
> Add files to access the powerpc NX-GZIP engine in user space.
>
> Signed-off-by: Bulent Abali <abali@us.ibm.com>
> Signed-off-by: Raphael Moreira Zinsly <rzinsly@linux.ibm.com>
> ---
> .../selftests/powerpc/nx-gzip/inc/crb.h | 170 ++++++++++++++++++
> .../selftests/powerpc/nx-gzip/inc/nx-gzip.h | 27 +++
> .../powerpc/nx-gzip/inc/nx-helpers.h | 53 ++++++
> .../selftests/powerpc/nx-gzip/inc/nx.h | 30 ++++
> 4 files changed, 280 insertions(+)
> create mode 100644 tools/testing/selftests/powerpc/nx-gzip/inc/crb.h
> create mode 100644 tools/testing/selftests/powerpc/nx-gzip/inc/nx-gzip.h
> create mode 100644 tools/testing/selftests/powerpc/nx-gzip/inc/nx-helpers.h
> create mode 100644 tools/testing/selftests/powerpc/nx-gzip/inc/nx.h
>
> diff --git a/tools/testing/selftests/powerpc/nx-gzip/inc/crb.h b/tools/testing/selftests/powerpc/nx-gzip/inc/crb.h
> new file mode 100644
> index 000000000000..6af25fb8461a
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/nx-gzip/inc/crb.h
> @@ -0,0 +1,170 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#ifndef __CRB_H
> +#define __CRB_H
> +#include <linux/types.h>
> +
> +typedef unsigned char u8;
> +typedef unsigned int u32;
> +typedef unsigned long long u64;
> +
> +/* From nx-842.h */
> +
> +/* CCW 842 CI/FC masks
> + * NX P8 workbook, section 4.3.1, figure 4-6
> + * "CI/FC Boundary by NX CT type"
> + */
> +#define CCW_CI_842 (0x00003ff8)
> +#define CCW_FC_842 (0x00000007)
> +
> +/* end - nx-842.h */
> +
> +#ifndef __aligned
> +#define __aligned(x) __attribute__((aligned(x)))
> +#endif
> +
> +#ifndef __packed
> +#define __packed __attribute__((packed))
> +#endif
> +
> +/* Chapter 6.5.8 Coprocessor-Completion Block (CCB) */
> +
> +#define CCB_VALUE (0x3fffffffffffffff)
> +#define CCB_ADDRESS (0xfffffffffffffff8)
> +#define CCB_CM (0x0000000000000007)
> +#define CCB_CM0 (0x0000000000000004)
> +#define CCB_CM12 (0x0000000000000003)
> +
> +#define CCB_CM0_ALL_COMPLETIONS (0x0)
> +#define CCB_CM0_LAST_IN_CHAIN (0x4)
> +#define CCB_CM12_STORE (0x0)
> +#define CCB_CM12_INTERRUPT (0x1)
> +
> +#define CCB_SIZE (0x10)
> +#define CCB_ALIGN CCB_SIZE
> +
> +struct coprocessor_completion_block {
> + __be64 value;
> + __be64 address;
> +} __packed __aligned(CCB_ALIGN);
> +
> +
> +/* Chapter 6.5.7 Coprocessor-Status Block (CSB) */
> +
> +#define CSB_V (0x80)
> +#define CSB_F (0x04)
> +#define CSB_CH (0x03)
> +#define CSB_CE_INCOMPLETE (0x80)
> +#define CSB_CE_TERMINATION (0x40)
> +#define CSB_CE_TPBC (0x20)
> +
> +#define CSB_CC_SUCCESS (0)
> +#define CSB_CC_INVALID_ALIGN (1)
> +#define CSB_CC_OPERAND_OVERLAP (2)
> +#define CSB_CC_DATA_LENGTH (3)
> +#define CSB_CC_TRANSLATION (5)
> +#define CSB_CC_PROTECTION (6)
> +#define CSB_CC_RD_EXTERNAL (7)
> +#define CSB_CC_INVALID_OPERAND (8)
> +#define CSB_CC_PRIVILEGE (9)
> +#define CSB_CC_INTERNAL (10)
> +#define CSB_CC_WR_EXTERNAL (12)
> +#define CSB_CC_NOSPC (13)
> +#define CSB_CC_EXCESSIVE_DDE (14)
> +#define CSB_CC_WR_TRANSLATION (15)
> +#define CSB_CC_WR_PROTECTION (16)
> +#define CSB_CC_UNKNOWN_CODE (17)
> +#define CSB_CC_ABORT (18)
> +#define CSB_CC_TRANSPORT (20)
> +#define CSB_CC_SEGMENTED_DDL (31)
> +#define CSB_CC_PROGRESS_POINT (32)
> +#define CSB_CC_DDE_OVERFLOW (33)
> +#define CSB_CC_SESSION (34)
> +#define CSB_CC_PROVISION (36)
> +#define CSB_CC_CHAIN (37)
> +#define CSB_CC_SEQUENCE (38)
> +#define CSB_CC_HW (39)
> +
> +#define CSB_SIZE (0x10)
> +#define CSB_ALIGN CSB_SIZE
> +
> +struct coprocessor_status_block {
> + u8 flags;
> + u8 cs;
> + u8 cc;
> + u8 ce;
> + __be32 count;
> + __be64 address;
> +} __packed __aligned(CSB_ALIGN);
> +
> +
> +/* Chapter 6.5.10 Data-Descriptor List (DDL)
> + * each list contains one or more Data-Descriptor Entries (DDE)
> + */
> +
> +#define DDE_P (0x8000)
> +
> +#define DDE_SIZE (0x10)
> +#define DDE_ALIGN DDE_SIZE
> +
> +struct data_descriptor_entry {
> + __be16 flags;
> + u8 count;
> + u8 index;
> + __be32 length;
> + __be64 address;
> +} __packed __aligned(DDE_ALIGN);
> +
> +
> +/* Chapter 6.5.2 Coprocessor-Request Block (CRB) */
> +
> +#define CRB_SIZE (0x80)
> +#define CRB_ALIGN (0x100) /* Errata: requires 256 alignment */
> +
> +
> +/* Coprocessor Status Block field
> + * ADDRESS address of CSB
> + * C CCB is valid
> + * AT 0 = addrs are virtual, 1 = addrs are phys
> + * M enable perf monitor
> + */
> +#define CRB_CSB_ADDRESS (0xfffffffffffffff0)
> +#define CRB_CSB_C (0x0000000000000008)
> +#define CRB_CSB_AT (0x0000000000000002)
> +#define CRB_CSB_M (0x0000000000000001)
> +
> +struct coprocessor_request_block {
> + __be32 ccw;
> + __be32 flags;
> + __be64 csb_addr;
> +
> + struct data_descriptor_entry source;
> + struct data_descriptor_entry target;
> +
> + struct coprocessor_completion_block ccb;
> +
> + u8 reserved[48];
> +
> + struct coprocessor_status_block csb;
> +} __packed __aligned(CRB_ALIGN);
> +
> +#define crb_csb_addr(c) __be64_to_cpu(c->csb_addr)
> +#define crb_nx_fault_addr(c) __be64_to_cpu(c->stamp.nx.fault_storage_addr)
> +#define crb_nx_flags(c) c->stamp.nx.flags
> +#define crb_nx_fault_status(c) c->stamp.nx.fault_status
> +#define crb_nx_pswid(c) c->stamp.nx.pswid;
> +
> +
> +/* RFC02167 Initiate Coprocessor Instructions document
> + * Chapter 8.2.1.1.1 RS
> + * Chapter 8.2.3 Coprocessor Directive
> + * Chapter 8.2.4 Execution
> + *
> + * The CCW must be converted to BE before passing to icswx()
> + */
> +
> +#define CCW_PS (0xff000000)
> +#define CCW_CT (0x00ff0000)
> +#define CCW_CD (0x0000ffff)
> +#define CCW_CL (0x0000c000)
> +
> +#endif
> diff --git a/tools/testing/selftests/powerpc/nx-gzip/inc/nx-gzip.h b/tools/testing/selftests/powerpc/nx-gzip/inc/nx-gzip.h
> new file mode 100644
> index 000000000000..75482c45574d
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/nx-gzip/inc/nx-gzip.h
> @@ -0,0 +1,27 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright 2020 IBM Corp.
> + *
> + */
> +
> +#ifndef _UAPI_MISC_VAS_H
> +#define _UAPI_MISC_VAS_H
> +
> +#include <asm/ioctl.h>
> +
> +#define VAS_FLAGS_PIN_WINDOW 0x1
> +#define VAS_FLAGS_HIGH_PRI 0x2
> +
> +#define VAS_FTW_SETUP _IOW('v', 1, struct vas_gzip_setup_attr)
> +#define VAS_842_TX_WIN_OPEN _IOW('v', 2, struct vas_gzip_setup_attr)
> +#define VAS_GZIP_TX_WIN_OPEN _IOW('v', 0x20, struct vas_gzip_setup_attr)
> +
> +struct vas_gzip_setup_attr {
> + int32_t version;
> + int16_t vas_id;
> + int16_t reserved1;
> + int64_t flags;
> + int64_t reserved2[6];
> +};
> +
> +#endif /* _UAPI_MISC_VAS_H */
> diff --git a/tools/testing/selftests/powerpc/nx-gzip/inc/nx-helpers.h b/tools/testing/selftests/powerpc/nx-gzip/inc/nx-helpers.h
> new file mode 100644
> index 000000000000..201cf9f86a97
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/nx-gzip/inc/nx-helpers.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#include <sys/time.h>
> +#include <asm/byteorder.h>
> +#include <stdint.h>
> +#include "crb.h"
> +
> +#define cpu_to_be32 __cpu_to_be32
> +#define cpu_to_be64 __cpu_to_be64
> +#define be32_to_cpu __be32_to_cpu
> +#define be64_to_cpu __be64_to_cpu
> +
> +/*
> + * Several helpers/macros below were copied from the tree
> + * (kernel.h, nx-842.h, nx-ftw.h, asm-compat.h etc)
> + */
> +
> +/* from kernel.h */
> +#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
> +#define __round_mask(x, y) ((__typeof__(x))((y)-1))
> +#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
> +#define round_down(x, y) ((x) & ~__round_mask(x, y))
> +
> +#define min_t(t, x, y) ((x) < (y) ? (x) : (y))
> +/*
> + * Get/Set bit fields. (from nx-842.h)
> + */
> +#define GET_FIELD(m, v) (((v) & (m)) >> MASK_LSH(m))
> +#define MASK_LSH(m) (__builtin_ffsl(m) - 1)
> +#define SET_FIELD(m, v, val) \
> + (((v) & ~(m)) | ((((typeof(v))(val)) << MASK_LSH(m)) & (m)))
> +
> +/* From asm-compat.h */
> +#define __stringify_in_c(...) #__VA_ARGS__
> +#define stringify_in_c(...) __stringify_in_c(__VA_ARGS__) " "
> +
> +#define pr_debug
> +#define pr_debug_ratelimited printf
> +#define pr_err printf
> +#define pr_err_ratelimited printf
> +
> +#define WARN_ON_ONCE(x) if (x) \
> + printf("WARNING: %s:%d\n", __func__, __LINE__)
> +
> +extern void dump_buffer(char *msg, char *buf, int len);
> +extern void *alloc_aligned_mem(int len, int align, char *msg);
> +extern void get_payload(char *buf, int len);
> +extern void time_add(struct timeval *in, int seconds, struct timeval *out);
> +
> +typedef int bool;
> +extern bool time_after(struct timeval *a, struct timeval *b);
> +extern long time_delta(struct timeval *a, struct timeval *b);
> +extern void dump_dde(struct data_descriptor_entry *dde, char *msg);
> +extern void copy_paste_crb_data(struct coprocessor_request_block *crb);
> diff --git a/tools/testing/selftests/powerpc/nx-gzip/inc/nx.h b/tools/testing/selftests/powerpc/nx-gzip/inc/nx.h
> new file mode 100644
> index 000000000000..08c93f7fb96c
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/nx-gzip/inc/nx.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later
> + *
> + * Copyright 2020 IBM Corp.
> + *
> + */
> +
> +#define NX_FUNC_COMP_842 1
> +#define NX_FUNC_COMP_GZIP 2
> +
> +typedef int bool;
> +
> +struct nx842_func_args {
> + bool use_crc;
> + bool decompress; /* true: decompress; false compress */
> + bool move_data;
> + int timeout; /* seconds */
> +};
> +
> +typedef struct {
> + int len;
> + char *buf;
> +} nxbuf_t;
> +
> +/* @function should be EFT (aka 842), GZIP etc */
> +extern void *nx_function_begin(int function, int pri);
> +
> +extern int nx_function(void *handle, nxbuf_t *in, nxbuf_t *out, void *arg);
> +
> +extern int nx_function_end(void *handle);
> +
> --
> 2.21.0
^ permalink raw reply
* Re: Slub: Increased mem consumption on cpu,mem-less node powerpc guest
From: Srikar Dronamraju @ 2020-03-18 3:20 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Sachin Sant, Andrew Morton, linuxppc-dev, aneesh.kumar, bharata,
Pekka Enberg, linux-mm, David Rientjes, Christoph Lameter,
Michal Hocko, Joonsoo Kim
In-Reply-To: <080b2d00-76ef-2187-ec78-c9d181ef1701@suse.cz>
* Vlastimil Babka <vbabka@suse.cz> [2020-03-17 17:45:15]:
> On 3/17/20 5:25 PM, Srikar Dronamraju wrote:
> > * Vlastimil Babka <vbabka@suse.cz> [2020-03-17 16:56:04]:
> >
> >>
> >> I wonder why do you get a memory leak while Sachin in the same situation [1]
> >> gets a crash? I don't understand anything anymore.
> >
> > Sachin was testing on linux-next which has Kirill's patch which modifies
> > slub to use kmalloc_node instead of kmalloc. While Bharata is testing on
> > upstream, which doesn't have this.
>
> Yes, that Kirill's patch was about the memcg shrinker map allocation. But the
> patch hunk that Bharata posted as a "hack" that fixes the problem, it follows
> that there has to be something else that calls kmalloc_node(node) where node is
> one that doesn't have present pages.
>
> He mentions alloc_fair_sched_group() which has:
>
> for_each_possible_cpu(i) {
> cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
> GFP_KERNEL, cpu_to_node(i));
> ...
> se = kzalloc_node(sizeof(struct sched_entity),
> GFP_KERNEL, cpu_to_node(i));
>
Sachin's experiment.
Upstream-next/ memcg /
possible nodes were 0-31
online nodes were 0-1
kmalloc_node called for_each_node / for_each_possible_node.
This would crash while allocating slab from !N_ONLINE nodes.
Bharata's experiment.
Upstream
possible nodes were 0-1
online nodes were 0-1
kmalloc_node called for_each_online_node/ for_each_possible_cpu
i.e kmalloc is called for N_ONLINE nodes.
So wouldn't crash
Even if his possible nodes were 0-256. I don't think we have kmalloc_node
being called in !N_ONLINE nodes. Hence its not crashing.
If we see the above code that you quote, kzalloc_node is using cpu_to_node
which in Bharata's case will always return 1.
> I assume one of these structs is 1k and other 512 bytes (rounded) and that for
> some possible cpu's cpu_to_node(i) will be 0, which has no present pages. And as
> Bharata pasted, node_to_mem_node(0) = 0
> So this looks like the same scenario, but it doesn't crash? Is the node 0
> actually online here, and/or does it have N_NORMAL_MEMORY state?
I still dont have any clue on the leak though.
--
Thanks and Regards
Srikar Dronamraju
^ permalink raw reply
* [PATCH] soc: fsl: enable acpi support
From: Peng Ma @ 2020-03-18 2:56 UTC (permalink / raw)
To: leoyang.li, linuxppc-dev, linux-arm-kernel
Cc: ran.wang_1, Peng Ma, linux-kernel
This patch enables ACPI support in Rcpm driver.
Signed-off-by: Peng Ma <peng.ma@nxp.com>
---
drivers/soc/fsl/rcpm.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
index a093dbe..7da6bbd 100644
--- a/drivers/soc/fsl/rcpm.c
+++ b/drivers/soc/fsl/rcpm.c
@@ -13,6 +13,7 @@
#include <linux/slab.h>
#include <linux/suspend.h>
#include <linux/kernel.h>
+#include <linux/acpi.h>
#define RCPM_WAKEUP_CELL_MAX_SIZE 7
@@ -139,10 +140,17 @@ static const struct of_device_id rcpm_of_match[] = {
};
MODULE_DEVICE_TABLE(of, rcpm_of_match);
+static const struct acpi_device_id rcpm_imx_acpi_ids[] = {
+ {"NXP0012",},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, rcpm_imx_acpi_ids);
+
static struct platform_driver rcpm_driver = {
.driver = {
.name = "rcpm",
.of_match_table = rcpm_of_match,
+ .acpi_match_table = ACPI_PTR(rcpm_imx_acpi_ids),
.pm = &rcpm_pm_ops,
},
.probe = rcpm_probe,
--
2.9.5
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS 8a445cbcb9f5090cb07ec6cbb89a8a1fc99a0ff7
From: kbuild test robot @ 2020-03-18 2:50 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: 8a445cbcb9f5090cb07ec6cbb89a8a1fc99a0ff7 Automatic merge of branches 'master', 'next' and 'fixes' into merge
elapsed time: 785m
configs tested: 156
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm allyesconfig
arm64 allnoconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
arm64 allmodconfig
mips fuloong2e_defconfig
s390 defconfig
openrisc simple_smp_defconfig
riscv allnoconfig
s390 allyesconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
ia64 defconfig
arm allmodconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc generic-64bit_defconfig
parisc generic-32bit_defconfig
parisc allyesconfig
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002-20200317
i386 randconfig-a003-20200317
alpha randconfig-a001-20200317
m68k randconfig-a001-20200317
mips randconfig-a001-20200317
nds32 randconfig-a001-20200317
parisc randconfig-a001-20200317
h8300 randconfig-a001-20200318
sparc64 randconfig-a001-20200318
c6x randconfig-a001-20200318
nios2 randconfig-a001-20200318
microblaze randconfig-a001-20200318
csky randconfig-a001-20200318
openrisc randconfig-a001-20200318
s390 randconfig-a001-20200318
sh randconfig-a001-20200318
xtensa randconfig-a001-20200318
xtensa randconfig-a001-20200317
openrisc randconfig-a001-20200317
csky randconfig-a001-20200317
sh randconfig-a001-20200317
s390 randconfig-a001-20200317
x86_64 randconfig-b001-20200317
x86_64 randconfig-b002-20200317
x86_64 randconfig-b003-20200317
i386 randconfig-b001-20200317
i386 randconfig-b002-20200317
i386 randconfig-b003-20200317
x86_64 randconfig-c001-20200317
x86_64 randconfig-c002-20200317
x86_64 randconfig-c003-20200317
i386 randconfig-c001-20200317
i386 randconfig-c002-20200317
i386 randconfig-c003-20200317
x86_64 randconfig-d001-20200318
x86_64 randconfig-d002-20200318
x86_64 randconfig-d003-20200318
i386 randconfig-d001-20200318
i386 randconfig-d002-20200318
i386 randconfig-d003-20200318
x86_64 randconfig-e001-20200317
x86_64 randconfig-e002-20200317
x86_64 randconfig-e003-20200317
i386 randconfig-e001-20200317
i386 randconfig-e002-20200317
i386 randconfig-e003-20200317
x86_64 randconfig-g001-20200317
x86_64 randconfig-g002-20200317
x86_64 randconfig-g003-20200317
i386 randconfig-g001-20200317
i386 randconfig-g002-20200317
i386 randconfig-g003-20200317
arc randconfig-a001-20200318
arm randconfig-a001-20200318
arm64 randconfig-a001-20200318
ia64 randconfig-a001-20200318
powerpc randconfig-a001-20200318
sparc randconfig-a001-20200318
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
riscv allmodconfig
s390 zfcpdump_defconfig
s390 debug_defconfig
s390 allnoconfig
s390 allmodconfig
s390 alldefconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS 033c9d310e29706e46c05f4fe7e863b1f32939db
From: kbuild test robot @ 2020-03-18 0:55 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: 033c9d310e29706e46c05f4fe7e863b1f32939db powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devmap PTE entries
elapsed time: 669m
configs tested: 156
configs skipped: 7
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm allyesconfig
arm64 allnoconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
arm64 allmodconfig
mips fuloong2e_defconfig
s390 defconfig
openrisc simple_smp_defconfig
riscv allnoconfig
s390 allyesconfig
powerpc allnoconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
ia64 defconfig
arm allmodconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc defconfig
arc allyesconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc defconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002-20200317
i386 randconfig-a003-20200317
alpha randconfig-a001-20200317
m68k randconfig-a001-20200317
mips randconfig-a001-20200317
nds32 randconfig-a001-20200317
parisc randconfig-a001-20200317
c6x randconfig-a001-20200317
h8300 randconfig-a001-20200317
microblaze randconfig-a001-20200317
nios2 randconfig-a001-20200317
sparc64 randconfig-a001-20200317
csky randconfig-a001-20200318
openrisc randconfig-a001-20200318
s390 randconfig-a001-20200318
sh randconfig-a001-20200318
xtensa randconfig-a001-20200318
csky randconfig-a001-20200317
openrisc randconfig-a001-20200317
s390 randconfig-a001-20200317
sh randconfig-a001-20200317
xtensa randconfig-a001-20200317
x86_64 randconfig-b001-20200317
x86_64 randconfig-b002-20200317
x86_64 randconfig-b003-20200317
i386 randconfig-b001-20200317
i386 randconfig-b002-20200317
i386 randconfig-b003-20200317
x86_64 randconfig-c001-20200317
x86_64 randconfig-c002-20200317
x86_64 randconfig-c003-20200317
i386 randconfig-c001-20200317
i386 randconfig-c002-20200317
i386 randconfig-c003-20200317
x86_64 randconfig-d001-20200318
x86_64 randconfig-d002-20200318
x86_64 randconfig-d003-20200318
i386 randconfig-d001-20200318
i386 randconfig-d002-20200318
i386 randconfig-d003-20200318
x86_64 randconfig-e001-20200317
x86_64 randconfig-e002-20200317
x86_64 randconfig-e003-20200317
i386 randconfig-e001-20200317
i386 randconfig-e002-20200317
i386 randconfig-e003-20200317
x86_64 randconfig-g001-20200317
x86_64 randconfig-g002-20200317
x86_64 randconfig-g003-20200317
i386 randconfig-g001-20200317
i386 randconfig-g002-20200317
i386 randconfig-g003-20200317
arc randconfig-a001-20200318
arm randconfig-a001-20200318
arm64 randconfig-a001-20200318
ia64 randconfig-a001-20200318
powerpc randconfig-a001-20200318
sparc randconfig-a001-20200318
riscv allmodconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 zfcpdump_defconfig
s390 debug_defconfig
s390 allnoconfig
s390 allmodconfig
s390 alldefconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
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 af3d0a68698c7e5df8b72267086b23422a3954bb
From: kbuild test robot @ 2020-03-18 0:55 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: af3d0a68698c7e5df8b72267086b23422a3954bb powerpc/kasan: Fix shadow memory protection with CONFIG_KASAN_VMALLOC
elapsed time: 2837m
configs tested: 251
configs skipped: 218
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
parisc generic-32bit_defconfig
mips allyesconfig
riscv nommu_virt_defconfig
h8300 edosk2674_defconfig
mips fuloong2e_defconfig
s390 defconfig
m68k sun3_defconfig
sparc defconfig
ia64 defconfig
powerpc defconfig
riscv allnoconfig
s390 alldefconfig
s390 allyesconfig
sparc64 defconfig
sh titan_defconfig
nios2 3c120_defconfig
riscv rv32_defconfig
i386 defconfig
nds32 allnoconfig
powerpc ppc64_defconfig
powerpc allnoconfig
ia64 allnoconfig
parisc allnoconfig
s390 debug_defconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips malta_kvm_defconfig
parisc allyesconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200316
x86_64 randconfig-a002-20200316
x86_64 randconfig-a003-20200316
i386 randconfig-a001-20200316
i386 randconfig-a002-20200316
i386 randconfig-a003-20200316
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002-20200317
i386 randconfig-a003-20200317
x86_64 randconfig-a001-20200318
x86_64 randconfig-a002-20200318
x86_64 randconfig-a003-20200318
i386 randconfig-a001-20200318
i386 randconfig-a002-20200318
i386 randconfig-a003-20200318
alpha randconfig-a001-20200317
m68k randconfig-a001-20200317
mips randconfig-a001-20200317
nds32 randconfig-a001-20200317
parisc randconfig-a001-20200317
riscv randconfig-a001-20200317
alpha randconfig-a001-20200316
m68k randconfig-a001-20200316
mips randconfig-a001-20200316
nds32 randconfig-a001-20200316
parisc randconfig-a001-20200316
riscv randconfig-a001-20200316
c6x randconfig-a001-20200317
h8300 randconfig-a001-20200317
microblaze randconfig-a001-20200317
nios2 randconfig-a001-20200317
sparc64 randconfig-a001-20200317
c6x randconfig-a001-20200316
h8300 randconfig-a001-20200316
microblaze randconfig-a001-20200316
nios2 randconfig-a001-20200316
sparc64 randconfig-a001-20200316
csky randconfig-a001-20200317
openrisc randconfig-a001-20200317
s390 randconfig-a001-20200317
sh randconfig-a001-20200317
xtensa randconfig-a001-20200317
csky randconfig-a001-20200318
openrisc randconfig-a001-20200318
s390 randconfig-a001-20200318
sh randconfig-a001-20200318
xtensa randconfig-a001-20200318
csky randconfig-a001-20200316
openrisc randconfig-a001-20200316
s390 randconfig-a001-20200316
sh randconfig-a001-20200316
xtensa randconfig-a001-20200316
x86_64 randconfig-b001-20200316
x86_64 randconfig-b002-20200316
x86_64 randconfig-b003-20200316
i386 randconfig-b001-20200316
i386 randconfig-b002-20200316
i386 randconfig-b003-20200316
x86_64 randconfig-b001-20200317
x86_64 randconfig-b002-20200317
x86_64 randconfig-b003-20200317
i386 randconfig-b001-20200317
i386 randconfig-b002-20200317
i386 randconfig-b003-20200317
x86_64 randconfig-b001-20200318
x86_64 randconfig-b002-20200318
x86_64 randconfig-b003-20200318
i386 randconfig-b001-20200318
i386 randconfig-b002-20200318
i386 randconfig-b003-20200318
x86_64 randconfig-c001-20200317
x86_64 randconfig-c002-20200317
x86_64 randconfig-c003-20200317
i386 randconfig-c001-20200317
i386 randconfig-c002-20200317
i386 randconfig-c003-20200317
x86_64 randconfig-c001-20200316
x86_64 randconfig-c002-20200316
x86_64 randconfig-c003-20200316
i386 randconfig-c001-20200316
i386 randconfig-c002-20200316
i386 randconfig-c003-20200316
x86_64 randconfig-d001-20200316
x86_64 randconfig-d002-20200316
x86_64 randconfig-d003-20200316
i386 randconfig-d001-20200316
i386 randconfig-d002-20200316
i386 randconfig-d003-20200316
x86_64 randconfig-d001-20200317
x86_64 randconfig-d002-20200317
x86_64 randconfig-d003-20200317
i386 randconfig-d001-20200317
i386 randconfig-d002-20200317
i386 randconfig-d003-20200317
x86_64 randconfig-e001-20200316
x86_64 randconfig-e002-20200316
x86_64 randconfig-e003-20200316
i386 randconfig-e001-20200316
i386 randconfig-e002-20200316
i386 randconfig-e003-20200316
x86_64 randconfig-e001-20200317
x86_64 randconfig-e002-20200317
x86_64 randconfig-e003-20200317
i386 randconfig-e001-20200317
i386 randconfig-e002-20200317
i386 randconfig-e003-20200317
x86_64 randconfig-f001-20200316
x86_64 randconfig-f002-20200316
x86_64 randconfig-f003-20200316
i386 randconfig-f001-20200316
i386 randconfig-f002-20200316
i386 randconfig-f003-20200316
x86_64 randconfig-f001-20200317
x86_64 randconfig-f002-20200317
x86_64 randconfig-f003-20200317
i386 randconfig-f001-20200317
i386 randconfig-f002-20200317
i386 randconfig-f003-20200317
x86_64 randconfig-g001-20200317
x86_64 randconfig-g002-20200317
x86_64 randconfig-g003-20200317
i386 randconfig-g001-20200317
i386 randconfig-g002-20200317
i386 randconfig-g003-20200317
x86_64 randconfig-g001-20200316
x86_64 randconfig-g002-20200316
x86_64 randconfig-g003-20200316
i386 randconfig-g001-20200316
i386 randconfig-g002-20200316
i386 randconfig-g003-20200316
x86_64 randconfig-h001-20200317
x86_64 randconfig-h002-20200317
x86_64 randconfig-h003-20200317
i386 randconfig-h001-20200317
i386 randconfig-h002-20200317
i386 randconfig-h003-20200317
x86_64 randconfig-h001-20200316
x86_64 randconfig-h002-20200316
x86_64 randconfig-h003-20200316
i386 randconfig-h001-20200316
i386 randconfig-h002-20200316
i386 randconfig-h003-20200316
arc randconfig-a001-20200317
arm randconfig-a001-20200317
arm64 randconfig-a001-20200317
ia64 randconfig-a001-20200317
powerpc randconfig-a001-20200317
sparc randconfig-a001-20200317
arc randconfig-a001-20200316
arm randconfig-a001-20200316
arm64 randconfig-a001-20200316
ia64 randconfig-a001-20200316
powerpc randconfig-a001-20200316
sparc randconfig-a001-20200316
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allmodconfig
s390 allnoconfig
s390 zfcpdump_defconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 fedora-25
x86_64 kexec
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2-clear
x86_64 rhel-7.6
---
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 59ed2adf393109c56d383e568f2e57bb5ad6d901
From: kbuild test robot @ 2020-03-18 0:55 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: 59ed2adf393109c56d383e568f2e57bb5ad6d901 powerpc/lib: Fix emulate_step() std test
elapsed time: 669m
configs tested: 161
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm allyesconfig
arm64 allnoconfig
arm allnoconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
arm64 allmodconfig
mips fuloong2e_defconfig
s390 defconfig
openrisc simple_smp_defconfig
riscv allnoconfig
s390 allyesconfig
powerpc allnoconfig
i386 allnoconfig
i386 alldefconfig
i386 allyesconfig
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
ia64 defconfig
arm allmodconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc allyesconfig
arc defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
powerpc defconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200317
x86_64 randconfig-a002-20200317
x86_64 randconfig-a003-20200317
i386 randconfig-a001-20200317
i386 randconfig-a002-20200317
i386 randconfig-a003-20200317
alpha randconfig-a001-20200317
m68k randconfig-a001-20200317
mips randconfig-a001-20200317
nds32 randconfig-a001-20200317
parisc randconfig-a001-20200317
c6x randconfig-a001-20200317
h8300 randconfig-a001-20200317
microblaze randconfig-a001-20200317
nios2 randconfig-a001-20200317
sparc64 randconfig-a001-20200317
csky randconfig-a001-20200318
openrisc randconfig-a001-20200318
s390 randconfig-a001-20200318
sh randconfig-a001-20200318
xtensa randconfig-a001-20200318
csky randconfig-a001-20200317
openrisc randconfig-a001-20200317
s390 randconfig-a001-20200317
sh randconfig-a001-20200317
xtensa randconfig-a001-20200317
x86_64 randconfig-b001-20200317
x86_64 randconfig-b002-20200317
x86_64 randconfig-b003-20200317
i386 randconfig-b001-20200317
i386 randconfig-b002-20200317
i386 randconfig-b003-20200317
x86_64 randconfig-c001-20200317
x86_64 randconfig-c002-20200317
x86_64 randconfig-c003-20200317
i386 randconfig-c001-20200317
i386 randconfig-c002-20200317
i386 randconfig-c003-20200317
x86_64 randconfig-d001-20200318
x86_64 randconfig-d002-20200318
x86_64 randconfig-d003-20200318
i386 randconfig-d001-20200318
i386 randconfig-d002-20200318
i386 randconfig-d003-20200318
x86_64 randconfig-e001-20200317
x86_64 randconfig-e002-20200317
x86_64 randconfig-e003-20200317
i386 randconfig-e001-20200317
i386 randconfig-e002-20200317
i386 randconfig-e003-20200317
x86_64 randconfig-g001-20200317
x86_64 randconfig-g002-20200317
x86_64 randconfig-g003-20200317
i386 randconfig-g001-20200317
i386 randconfig-g002-20200317
i386 randconfig-g003-20200317
arc randconfig-a001-20200317
ia64 randconfig-a001-20200317
arm randconfig-a001-20200317
arm64 randconfig-a001-20200317
sparc randconfig-a001-20200317
arc randconfig-a001-20200318
arm randconfig-a001-20200318
arm64 randconfig-a001-20200318
ia64 randconfig-a001-20200318
powerpc randconfig-a001-20200318
sparc randconfig-a001-20200318
riscv allmodconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 zfcpdump_defconfig
s390 debug_defconfig
s390 allnoconfig
s390 allmodconfig
s390 alldefconfig
sh allmodconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sh titan_defconfig
sparc allyesconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um defconfig
um i386_defconfig
um x86_64_defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: kbuild test robot @ 2020-03-17 23:51 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-s390, Dave Hansen, kbuild-all, Vasily Gorbik, linuxppc-dev,
Peter Zijlstra, x86, Heiko Carstens, lkml, Christian Borntraeger,
iommu, Ingo Molnar, Paul Mackerras, Tom Lendacky, Andy Lutomirski,
Thomas Gleixner, Robin Murphy, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <20200317111822.GA15609@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]
Hi Borislav,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/x86/mm]
[cannot apply to linux/master powerpc/next s390/features tip/x86/core linus/master v5.6-rc6 next-20200317]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Borislav-Petkov/treewide-Rename-unencrypted-to-decrypted/20200318-015738
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 17c4a2ae15a7aaefe84bdb271952678c5c9cd8e1
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
powerpc64-linux-ld: warning: orphan section `.gnu.hash' from `linker stubs' being placed in section `.gnu.hash'
powerpc64-linux-ld: kernel/dma/mapping.o: in function `.dma_pgprot':
>> mapping.c:(.text+0xc5c): undefined reference to `.force_dma_decrypted'
powerpc64-linux-ld: kernel/dma/mapping.o: in function `.dma_common_mmap':
mapping.c:(.text+0xcfc): undefined reference to `.force_dma_decrypted'
powerpc64-linux-ld: kernel/dma/direct.o: in function `.dma_direct_get_required_mask':
>> direct.c:(.text+0x920): undefined reference to `.force_dma_decrypted'
powerpc64-linux-ld: kernel/dma/direct.o: in function `.__dma_direct_alloc_pages':
direct.c:(.text+0x9fc): undefined reference to `.force_dma_decrypted'
>> powerpc64-linux-ld: direct.c:(.text+0xaa8): undefined reference to `.force_dma_decrypted'
powerpc64-linux-ld: kernel/dma/direct.o:direct.c:(.text+0xb28): more undefined references to `.force_dma_decrypted' follow
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25776 bytes --]
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: kbuild test robot @ 2020-03-17 23:16 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-s390, Dave Hansen, kbuild-all, Vasily Gorbik, linuxppc-dev,
Peter Zijlstra, x86, Heiko Carstens, lkml, Christian Borntraeger,
iommu, Ingo Molnar, Paul Mackerras, Tom Lendacky, Andy Lutomirski,
Thomas Gleixner, Robin Murphy, Christoph Hellwig,
Marek Szyprowski
In-Reply-To: <20200317111822.GA15609@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]
Hi Borislav,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/x86/mm]
[cannot apply to linux/master powerpc/next s390/features tip/x86/core linus/master v5.6-rc6 next-20200317]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Borislav-Petkov/treewide-Rename-unencrypted-to-decrypted/20200318-015738
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 17c4a2ae15a7aaefe84bdb271952678c5c9cd8e1
config: s390-zfcpdump_defconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 9.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.2.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
s390-linux-ld: kernel/dma/mapping.o: in function `dma_pgprot':
mapping.c:(.text+0x144): undefined reference to `force_dma_decrypted'
s390-linux-ld: kernel/dma/mapping.o: in function `dma_common_mmap':
mapping.c:(.text+0x1a4): undefined reference to `force_dma_decrypted'
s390-linux-ld: kernel/dma/direct.o: in function `dma_direct_get_required_mask':
direct.c:(.text+0xae): undefined reference to `force_dma_decrypted'
s390-linux-ld: kernel/dma/direct.o: in function `__dma_direct_alloc_pages':
direct.c:(.text+0x152): undefined reference to `force_dma_decrypted'
>> s390-linux-ld: direct.c:(.text+0x1e8): undefined reference to `force_dma_decrypted'
s390-linux-ld: kernel/dma/direct.o:direct.c:(.text+0x2e0): more undefined references to `force_dma_decrypted' follow
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 7925 bytes --]
^ permalink raw reply
* Re: [PATCH] cpufreq: powernv: Fix frame-size-overflow in powernv_cpufreq_work_fn
From: Daniel Axtens @ 2020-03-17 22:30 UTC (permalink / raw)
To: Pratik Rajesh Sampat, linux-pm, linuxppc-dev, linux-kernel,
psampat, pratik.r.sampat, ego
In-Reply-To: <20200316135743.57735-1-psampat@linux.ibm.com>
Hi Pratik,
Thanks.
I have checked:
- for matching puts/gets
- that all the '.' to '->' conversions, aud uses of '&' check out
- that the Snowpatch checks pass (https://patchwork.ozlabs.org/patch/1255580/)
On that basis:
Reviewed-by: Daniel Axtens <dja@axtens.net>
Regards,
Daniel
> The patch avoids allocating cpufreq_policy on stack hence fixing frame
> size overflow in 'powernv_cpufreq_work_fn'
>
> Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")
> Signed-off-by: Pratik Rajesh Sampat <psampat@linux.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index 56f4bc0d209e..20ee0661555a 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -902,6 +902,7 @@ static struct notifier_block powernv_cpufreq_reboot_nb = {
> void powernv_cpufreq_work_fn(struct work_struct *work)
> {
> struct chip *chip = container_of(work, struct chip, throttle);
> + struct cpufreq_policy *policy;
> unsigned int cpu;
> cpumask_t mask;
>
> @@ -916,12 +917,14 @@ void powernv_cpufreq_work_fn(struct work_struct *work)
> chip->restore = false;
> for_each_cpu(cpu, &mask) {
> int index;
> - struct cpufreq_policy policy;
>
> - cpufreq_get_policy(&policy, cpu);
> - index = cpufreq_table_find_index_c(&policy, policy.cur);
> - powernv_cpufreq_target_index(&policy, index);
> - cpumask_andnot(&mask, &mask, policy.cpus);
> + policy = cpufreq_cpu_get(cpu);
> + if (!policy)
> + continue;
> + index = cpufreq_table_find_index_c(policy, policy->cur);
> + powernv_cpufreq_target_index(policy, index);
> + cpumask_andnot(&mask, &mask, policy->cpus);
> + cpufreq_cpu_put(policy);
> }
> out:
> put_online_cpus();
> --
> 2.24.1
^ permalink raw reply
* Re: [PATCH v2 6/8] mm/memory_hotplug: unexport memhp_auto_online
From: Wei Yang @ 2020-03-17 22:24 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Baoquan He, Rafael J. Wysocki, linux-kernel,
Michal Hocko, linux-mm, Andrew Morton, Wei Yang, linuxppc-dev,
Oscar Salvador
In-Reply-To: <20200317104942.11178-7-david@redhat.com>
On Tue, Mar 17, 2020 at 11:49:40AM +0100, David Hildenbrand wrote:
>All in-tree users except the mm-core are gone. Let's drop the export.
>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Michal Hocko <mhocko@kernel.org>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>Cc: Baoquan He <bhe@redhat.com>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
>---
> mm/memory_hotplug.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>index 1a00b5a37ef6..2d2aae830b92 100644
>--- a/mm/memory_hotplug.c
>+++ b/mm/memory_hotplug.c
>@@ -71,7 +71,6 @@ bool memhp_auto_online;
> #else
> bool memhp_auto_online = true;
> #endif
>-EXPORT_SYMBOL_GPL(memhp_auto_online);
>
> static int __init setup_memhp_default_state(char *str)
> {
>--
>2.24.1
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH v2 4/8] powernv/memtrace: always online added memory blocks
From: Wei Yang @ 2020-03-17 22:04 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-hyperv, Baoquan He, Greg Kroah-Hartman, Rafael J. Wysocki,
linux-kernel, Michal Hocko, linux-mm, Paul Mackerras,
Andrew Morton, Wei Yang, linuxppc-dev, Oscar Salvador
In-Reply-To: <20200317104942.11178-5-david@redhat.com>
On Tue, Mar 17, 2020 at 11:49:38AM +0100, David Hildenbrand wrote:
>Let's always try to online the re-added memory blocks. In case add_memory()
>already onlined the added memory blocks, the first device_online() call
>will fail and stop processing the remaining memory blocks.
>
>This avoids manually having to check memhp_auto_online.
>
>Note: PPC always onlines all hotplugged memory directly from the kernel
>as well - something that is handled by user space on other
>architectures.
>
>Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>Cc: Paul Mackerras <paulus@samba.org>
>Cc: Michael Ellerman <mpe@ellerman.id.au>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>Cc: Michal Hocko <mhocko@kernel.org>
>Cc: Oscar Salvador <osalvador@suse.de>
>Cc: "Rafael J. Wysocki" <rafael@kernel.org>
>Cc: Baoquan He <bhe@redhat.com>
>Cc: Wei Yang <richard.weiyang@gmail.com>
>Cc: linuxppc-dev@lists.ozlabs.org
>Signed-off-by: David Hildenbrand <david@redhat.com>
Looks good.
Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
>---
> arch/powerpc/platforms/powernv/memtrace.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
>diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
>index d6d64f8718e6..13b369d2cc45 100644
>--- a/arch/powerpc/platforms/powernv/memtrace.c
>+++ b/arch/powerpc/platforms/powernv/memtrace.c
>@@ -231,16 +231,10 @@ static int memtrace_online(void)
> continue;
> }
>
>- /*
>- * If kernel isn't compiled with the auto online option
>- * we need to online the memory ourselves.
>- */
>- if (!memhp_auto_online) {
>- lock_device_hotplug();
>- walk_memory_blocks(ent->start, ent->size, NULL,
>- online_mem_block);
>- unlock_device_hotplug();
>- }
>+ lock_device_hotplug();
>+ walk_memory_blocks(ent->start, ent->size, NULL,
>+ online_mem_block);
>+ unlock_device_hotplug();
>
> /*
> * Memory was added successfully so clean up references to it
>--
>2.24.1
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 6/6] soc: fsl: qe: fix sparse warnings for ucc_slow.c
From: Li Yang @ 2020-03-17 22:01 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: lkml, linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Timur Tabi, Zhao Qiang
In-Reply-To: <b9c5a514-18c1-e36c-1595-2b86c9bfcff1@rasmusvillemoes.dk>
On Mon, Mar 16, 2020 at 4:08 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> On 12/03/2020 23.28, Li Yang wrote:
> > Fixes the following sparse warnings:
> >
> [snip]
> >
> > Also removed the unneccessary clearing for kzalloc'ed structure.
>
> Please don't mix that in the same patch, do it in a preparatory patch.
> That makes reviewing much easier.
Thanks for the review.
One of the few lines removed are actually causing sparse warning,
that's why I changed this together with the sparse fixes. I can add
all the lines removed in the log for better record.
>
> >
> > /* Get PRAM base */
> > uccs->us_pram_offset =
> > @@ -231,24 +224,24 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
> > /* clear bd buffer */
> > qe_iowrite32be(0, &bd->buf);
> > /* set bd status and length */
> > - qe_iowrite32be(0, (u32 *)bd);
> > + qe_iowrite32be(0, (u32 __iomem *)bd);
>
> It's cleaner to do two qe_iowrite16be to &bd->status and &bd->length,
> that avoids the casting altogether.
It probably is cleaner, but also slower for the bd manipulation that
can be in the hot path. The QE code has been using this way to
access/update the bd status and length together for a long time. And
I remembered that it could help to prevent synchronization issues for
accessing status and length separately.
It is probably cleaner to change the data structure to use union for
accessing status and length together. But that will need a big change
to update all the current users of the structure which I don't have
the time to do right now.
>
> > bd++;
> > }
> > /* for last BD set Wrap bit */
> > qe_iowrite32be(0, &bd->buf);
> > - qe_iowrite32be(cpu_to_be32(T_W), (u32 *)bd);
> > + qe_iowrite32be(T_W, (u32 __iomem *)bd);
>
> Yeah, and this is why. Who can actually keep track of where that bit
> ends up being set with that casting going on. Please use
> qe_iowrite16be() with an appropriately modified constant to the
> appropriate field instead of these games.
>
> And if the hardware doesn't support 16 bit writes, the definition of
> struct qe_bd is wrong and should have a single __be32 status_length
> field, with appropriate accessors defined.
Same comment as above.
>
> > /* Init Rx bds */
> > bd = uccs->rx_bd = qe_muram_addr(uccs->rx_base_offset);
> > for (i = 0; i < us_info->rx_bd_ring_len - 1; i++) {
> > /* set bd status and length */
> > - qe_iowrite32be(0, (u32 *)bd);
> > + qe_iowrite32be(0, (u32 __iomem *)bd);
>
> Same.
>
> > /* clear bd buffer */
> > qe_iowrite32be(0, &bd->buf);
> > bd++;
> > }
> > /* for last BD set Wrap bit */
> > - qe_iowrite32be(cpu_to_be32(R_W), (u32 *)bd);
> > + qe_iowrite32be(R_W, (u32 __iomem *)bd);
>
> Same.
>
> > qe_iowrite32be(0, &bd->buf);
> >
> > /* Set GUMR (For more details see the hardware spec.). */
> > @@ -273,8 +266,8 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct ucc_slow_private ** ucc
> > qe_iowrite32be(gumr, &us_regs->gumr_h);
> >
> > /* gumr_l */
> > - gumr = us_info->tdcr | us_info->rdcr | us_info->tenc | us_info->renc |
> > - us_info->diag | us_info->mode;
> > + gumr = (u32)us_info->tdcr | (u32)us_info->rdcr | (u32)us_info->tenc |
> > + (u32)us_info->renc | (u32)us_info->diag | (u32)us_info->mode;
>
> Are the tdcr, rdcr, tenc, renc fields actually set anywhere (the same
> for the diag and mode, but word-grepping for those give way too many
> false positives)? They seem to be a somewhat pointless split out of the
> bitfields of gumr_l, and not populated anywhere?. That's not directly
> related to this patch, of course, but getting rid of them first (if they
> are indeed completely unused) might make the sparse cleanup a little
> simpler.
I would agree with you that is not neccessary to create different enum
types for these bits in the same register in the first place. But I
would like to prevent aggressive cleanups of this driver for old
hardware that is becoming harder and harder to be thoroughly tested
right now. These fields are probably not used by the in tree ucc_uart
driver right now. But as a generic library for QE, I think it is
harmless to keep these simple code there for potentially customized
version of the uart driver or other ucc slow drivers.
Regards,
Leo
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Thomas Gleixner @ 2020-03-17 22:01 UTC (permalink / raw)
To: Borislav Petkov, Dave Hansen
Cc: Schofield, Alison, Peter Zijlstra, Dave Hansen, Heiko Carstens,
Paul Mackerras, Christoph Hellwig, Marek Szyprowski, linux-s390,
x86, Christian Borntraeger, Ingo Molnar, Borislav Petkov,
Tom Lendacky, Vasily Gorbik, Shutemov, Kirill, Andy Lutomirski,
Robin Murphy, lkml, iommu, linuxppc-dev
In-Reply-To: <20200317210602.GG15609@zn.tnic>
Borislav Petkov <bp@alien8.de> writes:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>> > Back then when the whole SME machinery started getting mainlined, it
>> > was agreed that for simplicity, clarity and sanity's sake, the terms
>> > denoting encrypted and not-encrypted memory should be "encrypted" and
>> > "decrypted". And the majority of the code sticks to that convention
>> > except those two. So rename them.
>>
>> Don't "unencrypted" and "decrypted" mean different things?
>>
>> Unencrypted to me means "encryption was never used for this data".
>>
>> Decrypted means "this was/is encrypted but here is a plaintext copy".
>
> Maybe but linguistical semantics is not the point here.
>
> The idea is to represent a "binary" concept of memory being encrypted
> or memory being not encrypted. And at the time we decided to use
> "encrypted" and "decrypted" for those two things.
>
> Do you see the need to differentiate a third "state", so to speak, of
> memory which was never encrypted?
I think so.
encrypted data is something you can't use without having the key
decrypted data is the plaintext copy of something encrypted, so
it might be of sensible nature.
unencrypted data can still be sensible, but nothing ever bothered to
encrypt it in the first place.
So having this distinction is useful in terms of setting the context
straight.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Joe Perches @ 2020-03-17 21:34 UTC (permalink / raw)
To: Dave Hansen, Borislav Petkov
Cc: Schofield, Alison, Peter Zijlstra, Dave Hansen, Heiko Carstens,
Paul Mackerras, Christoph Hellwig, Marek Szyprowski, linux-s390,
x86, Christian Borntraeger, Ingo Molnar, Borislav Petkov,
Tom Lendacky, Vasily Gorbik, Shutemov, Kirill, Andy Lutomirski,
Thomas Gleixner, Robin Murphy, lkml, iommu, linuxppc-dev
In-Reply-To: <f3e520c6-f455-9c82-abfc-d014ca63eeb5@intel.com>
On Tue, 2020-03-17 at 14:24 -0700, Dave Hansen wrote:
> On 3/17/20 2:06 PM, Borislav Petkov wrote:
> > On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
> > > On 3/17/20 4:18 AM, Borislav Petkov wrote:
> > > > Back then when the whole SME machinery started getting mainlined, it
> > > > was agreed that for simplicity, clarity and sanity's sake, the terms
> > > > denoting encrypted and not-encrypted memory should be "encrypted" and
> > > > "decrypted". And the majority of the code sticks to that convention
> > > > except those two. So rename them.
> > > Don't "unencrypted" and "decrypted" mean different things?
> > >
> > > Unencrypted to me means "encryption was never used for this data".
> > >
> > > Decrypted means "this was/is encrypted but here is a plaintext copy".
> > Maybe but linguistical semantics is not the point here.
> >
> > The idea is to represent a "binary" concept of memory being encrypted
> > or memory being not encrypted. And at the time we decided to use
> > "encrypted" and "decrypted" for those two things.
>
> Yeah, agreed. We're basically trying to name "!encrypted".
>
> > Do you see the need to differentiate a third "state", so to speak, of
> > memory which was never encrypted?
>
> No, there are just two states. I just think the "!encrypted" case
> should not be called "decrypted".
Nor do I, it's completely misleading.
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Borislav Petkov @ 2020-03-17 21:31 UTC (permalink / raw)
To: Dave Hansen
Cc: Schofield, Alison, Peter Zijlstra, Dave Hansen, Heiko Carstens,
Paul Mackerras, Christoph Hellwig, Marek Szyprowski, linux-s390,
x86, Christian Borntraeger, Ingo Molnar, Tom Lendacky,
Vasily Gorbik, Shutemov, Kirill, Andy Lutomirski, Thomas Gleixner,
Robin Murphy, lkml, iommu, linuxppc-dev
In-Reply-To: <f3e520c6-f455-9c82-abfc-d014ca63eeb5@intel.com>
On Tue, Mar 17, 2020 at 02:24:59PM -0700, Dave Hansen wrote:
> No, there are just two states. I just think the "!encrypted" case
> should not be called "decrypted".
Yeah, we suck at naming - news at 11! :-)
I believe we even considered things like "encrypted" vs "clear" but
that sucked too. ;-\
In any case, that ship has sailed now and having two as differently as
possible looking words to denote the two "states" should be good enough
for our purposes...
Oh well.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Dave Hansen @ 2020-03-17 21:24 UTC (permalink / raw)
To: Borislav Petkov
Cc: Schofield, Alison, Peter Zijlstra, Dave Hansen, Heiko Carstens,
Paul Mackerras, Christoph Hellwig, Marek Szyprowski, linux-s390,
x86, Christian Borntraeger, Ingo Molnar, Borislav Petkov,
Tom Lendacky, Vasily Gorbik, Shutemov, Kirill, Andy Lutomirski,
Thomas Gleixner, Robin Murphy, lkml, iommu, linuxppc-dev
In-Reply-To: <20200317210602.GG15609@zn.tnic>
On 3/17/20 2:06 PM, Borislav Petkov wrote:
> On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
>> On 3/17/20 4:18 AM, Borislav Petkov wrote:
>>> Back then when the whole SME machinery started getting mainlined, it
>>> was agreed that for simplicity, clarity and sanity's sake, the terms
>>> denoting encrypted and not-encrypted memory should be "encrypted" and
>>> "decrypted". And the majority of the code sticks to that convention
>>> except those two. So rename them.
>> Don't "unencrypted" and "decrypted" mean different things?
>>
>> Unencrypted to me means "encryption was never used for this data".
>>
>> Decrypted means "this was/is encrypted but here is a plaintext copy".
> Maybe but linguistical semantics is not the point here.
>
> The idea is to represent a "binary" concept of memory being encrypted
> or memory being not encrypted. And at the time we decided to use
> "encrypted" and "decrypted" for those two things.
Yeah, agreed. We're basically trying to name "!encrypted".
> Do you see the need to differentiate a third "state", so to speak, of
> memory which was never encrypted?
No, there are just two states. I just think the "!encrypted" case
should not be called "decrypted".
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Borislav Petkov @ 2020-03-17 21:06 UTC (permalink / raw)
To: Dave Hansen
Cc: Schofield, Alison, Peter Zijlstra, Dave Hansen, Heiko Carstens,
Paul Mackerras, Christoph Hellwig, Marek Szyprowski, linux-s390,
x86, Christian Borntraeger, Ingo Molnar, Borislav Petkov,
Tom Lendacky, Vasily Gorbik, Shutemov, Kirill, Andy Lutomirski,
Thomas Gleixner, Robin Murphy, lkml, iommu, linuxppc-dev
In-Reply-To: <2cb4a8ae-3b13-67bd-c021-aee47fdf58c5@intel.com>
On Tue, Mar 17, 2020 at 01:35:12PM -0700, Dave Hansen wrote:
> On 3/17/20 4:18 AM, Borislav Petkov wrote:
> > Back then when the whole SME machinery started getting mainlined, it
> > was agreed that for simplicity, clarity and sanity's sake, the terms
> > denoting encrypted and not-encrypted memory should be "encrypted" and
> > "decrypted". And the majority of the code sticks to that convention
> > except those two. So rename them.
>
> Don't "unencrypted" and "decrypted" mean different things?
>
> Unencrypted to me means "encryption was never used for this data".
>
> Decrypted means "this was/is encrypted but here is a plaintext copy".
Maybe but linguistical semantics is not the point here.
The idea is to represent a "binary" concept of memory being encrypted
or memory being not encrypted. And at the time we decided to use
"encrypted" and "decrypted" for those two things.
Do you see the need to differentiate a third "state", so to speak, of
memory which was never encrypted?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] treewide: Rename "unencrypted" to "decrypted"
From: Dave Hansen @ 2020-03-17 20:35 UTC (permalink / raw)
To: Borislav Petkov, lkml, Schofield, Alison
Cc: linux-s390, Dave Hansen, Vasily Gorbik, Tom Lendacky,
Peter Zijlstra, x86, Heiko Carstens, linuxppc-dev,
Shutemov, Kirill, Christian Borntraeger, iommu, Ingo Molnar,
Paul Mackerras, Andy Lutomirski, Thomas Gleixner, Robin Murphy,
Christoph Hellwig, Marek Szyprowski
In-Reply-To: <20200317111822.GA15609@zn.tnic>
On 3/17/20 4:18 AM, Borislav Petkov wrote:
> Back then when the whole SME machinery started getting mainlined, it
> was agreed that for simplicity, clarity and sanity's sake, the terms
> denoting encrypted and not-encrypted memory should be "encrypted" and
> "decrypted". And the majority of the code sticks to that convention
> except those two. So rename them.
Don't "unencrypted" and "decrypted" mean different things?
Unencrypted to me means "encryption was never used for this data".
Decrypted means "this was/is encrypted but here is a plaintext copy".
This, for instance:
> +++ b/kernel/dma/direct.c
> @@ -26,7 +26,7 @@ unsigned int zone_dma_bits __ro_after_init = 24;
> static inline dma_addr_t phys_to_dma_direct(struct device *dev,
> phys_addr_t phys)
> {
> - if (force_dma_unencrypted(dev))
> + if (force_dma_decrypted(dev))
> return __phys_to_dma(dev, phys);
is referring to DMA that is not and never was encrypted. It's skipping
the encryption altogether. There's no act of "decryption" anywhere.
This, on the other hand, seems named wrong to me:
> /*
> * Macros to add or remove encryption attribute
> */
> #define pgprot_encrypted(prot) __pgprot(__sme_set(pgprot_val(prot)))
> #define pgprot_decrypted(prot) __pgprot(__sme_clr(pgprot_val(prot)))
This seems like it would be better named pgprot_unencrypted().
^ permalink raw reply
* Re: [PATCH V7 09/14] powerpc/vas: Update CSB and notify process for fault CRBs
From: Haren Myneni @ 2020-03-17 19:27 UTC (permalink / raw)
To: Michael Ellerman
Cc: mikey, herbert, npiggin, hch, oohall, sukadev, linuxppc-dev, ajd
In-Reply-To: <877dzj35z8.fsf@mpe.ellerman.id.au>
On Tue, 2020-03-17 at 16:28 +1100, Michael Ellerman wrote:
> Haren Myneni <haren@linux.ibm.com> writes:
> > For each fault CRB, update fault address in CRB (fault_storage_addr)
> > and translation error status in CSB so that user space can touch the
> > fault address and resend the request. If the user space passed invalid
> > CSB address send signal to process with SIGSEGV.
> >
> > Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> > Signed-off-by: Haren Myneni <haren@linux.ibm.com>
> > ---
> > arch/powerpc/platforms/powernv/vas-fault.c | 114 +++++++++++++++++++++++++++++
> > 1 file changed, 114 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/powernv/vas-fault.c b/arch/powerpc/platforms/powernv/vas-fault.c
> > index 1c6d5cc..751ce48 100644
> > --- a/arch/powerpc/platforms/powernv/vas-fault.c
> > +++ b/arch/powerpc/platforms/powernv/vas-fault.c
> > @@ -11,6 +11,7 @@
> > #include <linux/slab.h>
> > #include <linux/uaccess.h>
> > #include <linux/kthread.h>
> > +#include <linux/sched/signal.h>
> > #include <linux/mmu_context.h>
> > #include <asm/icswx.h>
> >
> > @@ -26,6 +27,118 @@
> > #define VAS_FAULT_WIN_FIFO_SIZE (4 << 20)
> >
> > /*
> > + * Update the CSB to indicate a translation error.
> > + *
> > + * If we are unable to update the CSB means copy_to_user failed due to
> > + * invalid csb_addr, send a signal to the process.
> > + *
> > + * Remaining settings in the CSB are based on wait_for_csb() of
> > + * NX-GZIP.
> > + */
> > +static void update_csb(struct vas_window *window,
> > + struct coprocessor_request_block *crb)
> > +{
> > + int rc;
> > + struct pid *pid;
> > + void __user *csb_addr;
> > + struct task_struct *tsk;
> > + struct kernel_siginfo info;
> > + struct coprocessor_status_block csb;
>
> csb is on the stack, and later copied to user, which is a risk for
> creating an infoleak.
>
> Also please use reverse Christmas tree layout for your variables.
>
> > +
> > + /*
> > + * NX user space windows can not be opened for task->mm=NULL
> > + * and faults will not be generated for kernel requests.
> > + */
> > + if (!window->mm || !window->user_win)
> > + return;
>
> If that's a should-never-happen condition then should it do a
> WARN_ON_ONCE() rather than silently returning?
Will add WARN_ON
>
> > + csb_addr = (void __user *)be64_to_cpu(crb->csb_addr);
> > +
> > + csb.cc = CSB_CC_TRANSLATION;
> > + csb.ce = CSB_CE_TERMINATION;
> > + csb.cs = 0;
> > + csb.count = 0;
> > +
> > + /*
> > + * NX operates and returns in BE format as defined CRB struct.
> > + * So return fault_storage_addr in BE as NX pastes in FIFO and
> > + * expects user space to convert to CPU format.
> > + */
> > + csb.address = crb->stamp.nx.fault_storage_addr;
> > + csb.flags = 0;
>
> I'm pretty sure this has initialised all the fields of csb.
>
> But, I'd still be much happier if you zeroed the whole struct to begin
> with, that way we know for sure we can't leak any uninitialised bytes to
> userspace. It's only 16 bytes so it shouldn't add any noticeable
> overhead.
Sure, will initialize csb
>
> > +
> > + pid = window->pid;
> > + tsk = get_pid_task(pid, PIDTYPE_PID);
> > + /*
> > + * Send window will be closed after processing all NX requests
> > + * and process exits after closing all windows. In multi-thread
> > + * applications, thread may not exists, but does not close FD
> > + * (means send window) upon exit. Parent thread (tgid) can use
> > + * and close the window later.
> > + * pid and mm references are taken when window is opened by
> > + * process (pid). So tgid is used only when child thread opens
> > + * a window and exits without closing it in multithread tasks.
> > + */
> > + if (!tsk) {
> > + pid = window->tgid;
> > + tsk = get_pid_task(pid, PIDTYPE_PID);
> > + /*
> > + * Parent thread will be closing window during its exit.
> > + * So should not get here.
> > + */
> > + if (!tsk)
> > + return;
>
> Similar question on WARN_ON_ONCE()
Yes, we can add WARN_ON
>
> > + }
> > +
> > + /* Return if the task is exiting. */
>
> Why? Just because it's no use? It's racy isn't it, so it can't be for
> correctness?
Yes process is exiting and no need to update CSB. We release the
task->usage refcount after copy_to_user().
>
> > + if (tsk->flags & PF_EXITING) {
> > + put_task_struct(tsk);
> > + return;
> > + }
> > +
> > + use_mm(window->mm);
>
> There's no check that csb_addr is actually pointing into userspace, but
> copy_to_user() does it for you.
>
> > + rc = copy_to_user(csb_addr, &csb, sizeof(csb));
> > + /*
> > + * User space polls on csb.flags (first byte). So add barrier
> > + * then copy first byte with csb flags update.
> > + */
> > + smp_mb();
>
> You only need to order the stores above vs the store below to csb.flags.
> So you should only need an smp_wmb() here.
Sure, will add
if (!rc) {
csb.flags = CSB_V;
smp_mb();
rc = copy_to_user(csb_addr, &csb, sizeof(u8));
}
>
> > + if (!rc) {
> > + csb.flags = CSB_V;
> > + rc = copy_to_user(csb_addr, &csb, sizeof(u8));
> > + }
> > + unuse_mm(window->mm);
> > + put_task_struct(tsk);
> > +
> > + /* Success */
> > + if (!rc)
> > + return;
> > +
> > + pr_debug("Invalid CSB address 0x%p signalling pid(%d)\n",
> > + csb_addr, pid_vnr(pid));
> > +
> > + clear_siginfo(&info);
> > + info.si_signo = SIGSEGV;
> > + info.si_errno = EFAULT;
> > + info.si_code = SEGV_MAPERR;
> > + info.si_addr = csb_addr;
> > +
> > + /*
> > + * process will be polling on csb.flags after request is sent to
> > + * NX. So generally CSB update should not fail except when an
> > + * application does not follow the process properly. So an error
> > + * message will be displayed and leave it to user space whether
> > + * to ignore or handle this signal.
> > + */
> > + rcu_read_lock();
> > + rc = kill_pid_info(SIGSEGV, &info, pid);
> > + rcu_read_unlock();
>
> Shouldn't this be using force_sig_fault_to_task() or another helper,
> rather than open-coding?
Applications or nxz library can ignore this signal based on si_addr or
take action like resend new request with valid csb_addr. Hence I did not
use force_sig_info_to_task().
>
> > +
> > + pr_devel("%s(): pid %d kill_proc_info() rc %d\n", __func__,
> > + pid_vnr(pid), rc);
> > +}
> > +
> > +/*
> > * Process valid CRBs in fault FIFO.
> > */
> > irqreturn_t vas_fault_thread_fn(int irq, void *data)
> > @@ -111,6 +224,7 @@ irqreturn_t vas_fault_thread_fn(int irq, void *data)
> > return IRQ_HANDLED;
> > }
> >
> > + update_csb(window, crb);
> > } while (true);
> > }
> >
> > --
> > 1.8.3.1
>
> cheers
^ permalink raw reply
* Re: [PATCH V7 08/14] powerpc/vas: Take reference to PID and mm for user space windows
From: Haren Myneni @ 2020-03-17 19:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: mikey, herbert, npiggin, hch, oohall, sukadev, linuxppc-dev, ajd
In-Reply-To: <87r1xrpqqh.fsf@mpe.ellerman.id.au>
On Tue, 2020-03-17 at 15:09 +1100, Michael Ellerman wrote:
> Haren Myneni <haren@linux.ibm.com> writes:
> > Process close windows after its requests are completed. In multi-thread
> > applications, child can open a window but release FD will not be called
> > upon its exit. Parent thread will be closing it later upon its exit.
>
> What if the parent exits first?
Thanks for the review.
If the parent exists, child thread will close the window when it exits.
So we should not get the case where window is still open.
>
> > The parent can also send NX requests with this window and NX can
> > generate page faults. After kernel handles the page fault, send
> > signal to process by using PID if CSB address is invalid. Parent
> > thread will not receive signal since its PID is different from the one
> > saved in vas_window. So use tgid in case if the task for the pid saved
> > in window is not running and send signal to its parent.
> >
> > To prevent reusing the pid until the window closed, take reference to
> > pid and task mm.
>
> That text is all very dense. Can you please flesh it out and reword it
> to clearly spell out what's going on in much more detail.
Sure, will update the commit description.
>
>
> > diff --git a/arch/powerpc/platforms/powernv/vas-window.c b/arch/powerpc/platforms/powernv/vas-window.c
> > index a45d81d..7587258 100644
> > --- a/arch/powerpc/platforms/powernv/vas-window.c
> > +++ b/arch/powerpc/platforms/powernv/vas-window.c
> > @@ -1266,8 +1300,17 @@ int vas_win_close(struct vas_window *window)
> > poll_window_castout(window);
> >
> > /* if send window, drop reference to matching receive window */
> > - if (window->tx_win)
> > + if (window->tx_win) {
> > + if (window->user_win) {
> > + /* Drop references to pid and mm */
> > + put_pid(window->pid);
> > + if (window->mm) {
> > + mmdrop(window->mm);
> > + mm_context_remove_copro(window->mm);
>
> That seems backward. Once you drop the reference the mm can be freed
> can't it?
Yes, will change.
>
> > + }
> > + }
> > put_rx_win(window->rxwin);
> > + }
> >
> > vas_window_free(window);
>
> cheers
^ permalink raw reply
* Re: [PATCH v2 5/8] hv_balloon: don't check for memhp_auto_online manually
From: David Hildenbrand @ 2020-03-17 18:46 UTC (permalink / raw)
To: linux-kernel
Cc: linux-hyperv, Stephen Hemminger, Baoquan He, Rafael J. Wysocki,
Haiyang Zhang, Wei Liu, Michal Hocko, linux-mm, Wei Yang,
Andrew Morton, K. Y. Srinivasan, linuxppc-dev, Vitaly Kuznetsov,
Oscar Salvador
In-Reply-To: <20200317104942.11178-6-david@redhat.com>
> @@ -1707,6 +1701,7 @@ static int balloon_probe(struct hv_device *dev,
> #ifdef CONFIG_MEMORY_HOTPLUG
> set_online_page_callback(&hv_online_page);
> register_memory_notifier(&hv_memory_nb);
> + init_completion(&dm_device.ol_waitevent);
I'll move this one line up.
> #endif
>
> hv_set_drvdata(dev, &dm_device);
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS
From: Mike Kravetz @ 2020-03-17 17:24 UTC (permalink / raw)
To: Christophe Leroy, Andrew Morton, Nishanth Aravamudan, Nick Piggin,
Adam Litke, Andi Kleen
Cc: linux-mm, linuxppc-dev, linux-kernel
In-Reply-To: <7e8c3a3c9a587b9cd8a2f146df32a421b961f3a2.1584432148.git.christophe.leroy@c-s.fr>
On 3/17/20 1:04 AM, Christophe Leroy wrote:
> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
> following build failure is encoutered:
>
> In file included from arch/powerpc/mm/fault.c:33:0:
> ./include/linux/hugetlb.h: In function 'hstate_inode':
> ./include/linux/hugetlb.h:477:9: error: implicit declaration of function 'HUGETLBFS_SB' [-Werror=implicit-function-declaration]
> return HUGETLBFS_SB(i->i_sb)->hstate;
> ^
> ./include/linux/hugetlb.h:477:30: error: invalid type argument of '->' (have 'int')
> return HUGETLBFS_SB(i->i_sb)->hstate;
> ^
>
> Gate hstate_inode() with CONFIG_HUGETLBFS instead of CONFIG_HUGETLB_PAGE.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Link: https://patchwork.ozlabs.org/patch/1255548/#2386036
> Fixes: a137e1cc6d6e ("hugetlbfs: per mount huge page sizes")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
As hugetlb.h evolved over time, I suspect nobody imagined a configuration
with CONFIG_HUGETLB_PAGE and not CONFIG_HUGETLBFS. This patch does address
the build issues. So,
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
However, there are many definitions in that file not behind #ifdef
CONFIG_HUGETLBFS that make no sense unless CONFIG_HUGETLBFS is defined.
Such cleanup is way beyond the scope of this patch/effort. I will add
it to the list of hugetlb/hugetlbfs things that can be cleaned up.
--
Mike Kravetz
^ permalink raw reply
* Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS
From: Mike Kravetz @ 2020-03-17 17:07 UTC (permalink / raw)
To: Christophe Leroy, Baoquan He
Cc: Nick Piggin, Andi Kleen, linux-kernel, linux-mm, Adam Litke,
Nishanth Aravamudan, Andrew Morton, linuxppc-dev
In-Reply-To: <ff480af2-d376-3b99-ba9e-36397ecde232@c-s.fr>
On 3/17/20 9:47 AM, Christophe Leroy wrote:
>
>
> Le 17/03/2020 à 17:40, Mike Kravetz a écrit :
>> On 3/17/20 1:43 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 17/03/2020 à 09:25, Baoquan He a écrit :
>>>> On 03/17/20 at 08:04am, Christophe Leroy wrote:
>>>>> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
>>>>> following build failure is encoutered:
>>>>
>>>> From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS?
>>>> I could misunderstand the def_bool, please correct me if I am wrong.
>>>
>>> AFAIU, it means that HUGETLBFS rely on HUGETLB_PAGE, by default HUGETLB_PAGE is not selected when HUGETLBFS is not. But it is still possible for an arch to select HUGETLB_PAGE without selecting HUGETLBFS when it uses huge pages for other purpose than hugetlb file system.
>>>
>>
>> Hi Christophe,
>>
>> Do you actually have a use case/example of using hugetlb pages without
>> hugetlbfs? I can understand that there are some use cases which never
>> use the filesystem interface. However, hugetlb support is so intertwined
>> with hugetlbfs, I am thinking there would be issues trying to use them
>> separately. I will look into this further.
>>
>
> Hi Mike,
>
> Series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=164620
>
> And especially patch 39 to 41.
>
Ah, ok. You are simply using a few interfaces in the hugetlb header files.
The huge pages created in your mappings are not PageHuge() pages.
--
Mike Kravetz
^ permalink raw reply
* Re: [PATCH] mm/hugetlb: Fix build failure with HUGETLB_PAGE but not HUGEBTLBFS
From: Christophe Leroy @ 2020-03-17 16:47 UTC (permalink / raw)
To: Mike Kravetz, Baoquan He
Cc: Nick Piggin, Andi Kleen, linux-kernel, linux-mm, Adam Litke,
Nishanth Aravamudan, Andrew Morton, linuxppc-dev
In-Reply-To: <a31c86c9-2f86-4f40-a367-5953037ee137@oracle.com>
Le 17/03/2020 à 17:40, Mike Kravetz a écrit :
> On 3/17/20 1:43 AM, Christophe Leroy wrote:
>>
>>
>> Le 17/03/2020 à 09:25, Baoquan He a écrit :
>>> On 03/17/20 at 08:04am, Christophe Leroy wrote:
>>>> When CONFIG_HUGETLB_PAGE is set but not CONFIG_HUGETLBFS, the
>>>> following build failure is encoutered:
>>>
>>> From the definition of HUGETLB_PAGE, isn't it relying on HUGETLBFS?
>>> I could misunderstand the def_bool, please correct me if I am wrong.
>>
>> AFAIU, it means that HUGETLBFS rely on HUGETLB_PAGE, by default HUGETLB_PAGE is not selected when HUGETLBFS is not. But it is still possible for an arch to select HUGETLB_PAGE without selecting HUGETLBFS when it uses huge pages for other purpose than hugetlb file system.
>>
>
> Hi Christophe,
>
> Do you actually have a use case/example of using hugetlb pages without
> hugetlbfs? I can understand that there are some use cases which never
> use the filesystem interface. However, hugetlb support is so intertwined
> with hugetlbfs, I am thinking there would be issues trying to use them
> separately. I will look into this further.
>
Hi Mike,
Series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=164620
And especially patch 39 to 41.
Thanks
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