* Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Bjorn Helgaas @ 2018-05-14 12:47 UTC (permalink / raw)
To: Nipun Gupta
Cc: robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, gregkh, hch, joro, m.szyprowski, shawnguo,
frowand.list, bhelgaas, iommu, linux-kernel, devicetree,
linux-arm-kernel, linuxppc-dev, linux-pci, bharat.bhushan,
stuyoder, laurentiu.tudor, leoyang.li
In-Reply-To: <1525069641-8523-6-git-send-email-nipun.gupta@nxp.com>
When you add the changleog, please also fix the subject typo:
- bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
^^^^^^^
+ bus: fsl-mc: support dma configure for devices on fsl-mc bus
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> index 5d8266c..624828b 100644
> --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> @@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> return 0;
> }
>
> +static int fsl_mc_dma_configure(struct device *dev)
> +{
> + struct device *dma_dev = dev;
> +
> + while (dev_is_fsl_mc(dma_dev))
> + dma_dev = dma_dev->parent;
> +
> + return of_dma_configure(dev, dma_dev->of_node, 0);
> +}
> +
> static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> @@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
> .name = "fsl-mc",
> .match = fsl_mc_bus_match,
> .uevent = fsl_mc_bus_uevent,
> + .dma_configure = fsl_mc_dma_configure,
> .dev_groups = fsl_mc_dev_groups,
> };
> EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
> @@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> mc_dev->icid = parent_mc_dev->icid;
> mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
> mc_dev->dev.dma_mask = &mc_dev->dma_mask;
> + mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
> dev_set_msi_domain(&mc_dev->dev,
> dev_get_msi_domain(&parent_mc_dev->dev));
> }
> @@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
> goto error_cleanup_dev;
> }
>
> - /* Objects are coherent, unless 'no shareability' flag set. */
> - if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
> - arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
> -
> /*
> * The device-specific probe callback will get invoked by device_add()
> */
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Florian Weimer @ 2018-05-14 12:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linuxram, Dave Hansen, Linux-MM, Linux API, linux-x86_64,
linux-arch, X86 ML, linuxppc-dev
In-Reply-To: <CALCETrUGjN8mhOaLqGcau-pPKm9TQW8k05hZrh52prRNdC5yQQ@mail.gmail.com>
On 05/09/2018 04:41 PM, Andy Lutomirski wrote:
> Hmm. I can get on board with the idea that fork() / clone() /
> pthread_create() are all just special cases of the idea that the thread
> that*calls* them should have the right pkey values, and the latter is
> already busted given our inability to asynchronously propagate the new mode
> in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point.
Ram, any suggestions for implementing this on POWER?
> One thing we could do, though: the current initual state on process
> creation is all access blocked on all keys. We could change it so that
> half the keys are fully blocked and half are read-only. Then we could add
> a PKEY_ALLOC_STRICT or similar that allocates a key with the correct
> initial state*and* does the setsignal thing. If there are no keys left
> with the correct initial state, then it fails.
The initial PKRU value can currently be configured by the system
administrator. I fear this approach has too many moving parts to be viable.
Thanks,
Florian
^ permalink raw reply
* [RFC][PATCH bpf v3 5/5] tools: bpftool: resolve call addresses without using imm field
From: Sandipan Das @ 2018-05-14 11:51 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
In-Reply-To: <20180514115118.8149-1-sandipan@linux.vnet.ibm.com>
Currently, we resolve the callee's address for a JITed function
call by using the imm field of the call instruction as an offset
from __bpf_call_base. If bpf_jit_kallsyms is enabled, we further
use this address to get the callee's kernel symbol's name.
For some architectures, such as powerpc64, the imm field is not
large enough to hold this offset. So, instead of assigning this
offset to the imm field, the verifier now assigns the subprog
id. Also, a list of kernel symbol addresses for all the JITed
functions is provided in the program info. We now use the imm
field as an index for this list to lookup a callee's symbol's
address and resolve its name.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
tools/bpf/bpftool/prog.c | 33 +++++++++++++++++++++++++++++++++
tools/bpf/bpftool/xlated_dumper.c | 24 +++++++++++++++++-------
tools/bpf/bpftool/xlated_dumper.h | 2 ++
3 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 9bdfdf2d3fbe..0ba947c7deec 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -428,6 +428,8 @@ static int do_dump(int argc, char **argv)
bool opcodes = false;
bool visual = false;
unsigned char *buf;
+ __u64 *addrs = NULL;
+ __u32 nr_addrs = 0;
__u32 *member_len;
__u64 *member_ptr;
ssize_t n;
@@ -496,11 +498,27 @@ static int do_dump(int argc, char **argv)
return -1;
}
+ if (info.nr_jited_funcs) {
+ nr_addrs = info.nr_jited_funcs;
+ addrs = (__u64 *) malloc(nr_addrs * sizeof(__u64));
+ if (!addrs) {
+ p_err("mem alloc failed");
+ free(buf);
+ close(fd);
+ return -1;
+ }
+ }
+
memset(&info, 0, sizeof(info));
*member_ptr = ptr_to_u64(buf);
*member_len = buf_size;
+ if (nr_addrs) {
+ info.jited_funcs = ptr_to_u64(addrs);
+ info.nr_jited_funcs = nr_addrs;
+ }
+
err = bpf_obj_get_info_by_fd(fd, &info, &len);
close(fd);
if (err) {
@@ -513,6 +531,11 @@ static int do_dump(int argc, char **argv)
goto err_free;
}
+ if (info.nr_jited_funcs > nr_addrs) {
+ p_err("too many addresses returned");
+ goto err_free;
+ }
+
if ((member_len == &info.jited_prog_len &&
info.jited_prog_insns == 0) ||
(member_len == &info.xlated_prog_len &&
@@ -558,6 +581,12 @@ static int do_dump(int argc, char **argv)
dump_xlated_cfg(buf, *member_len);
} else {
kernel_syms_load(&dd);
+
+ if (info.nr_jited_funcs) {
+ dd.jited_funcs = (u64 *) info.jited_funcs;
+ dd.nr_jited_funcs = info.nr_jited_funcs;
+ }
+
if (json_output)
dump_xlated_json(&dd, buf, *member_len, opcodes);
else
@@ -566,10 +595,14 @@ static int do_dump(int argc, char **argv)
}
free(buf);
+ if (nr_addrs)
+ free(addrs);
return 0;
err_free:
free(buf);
+ if (nr_addrs)
+ free(addrs);
return -1;
}
diff --git a/tools/bpf/bpftool/xlated_dumper.c b/tools/bpf/bpftool/xlated_dumper.c
index 7a3173b76c16..70943612b667 100644
--- a/tools/bpf/bpftool/xlated_dumper.c
+++ b/tools/bpf/bpftool/xlated_dumper.c
@@ -178,8 +178,12 @@ static const char *print_call_pcrel(struct dump_data *dd,
snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
"%+d#%s", insn->off, sym->name);
else
- snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
- "%+d#0x%lx", insn->off, address);
+ if (address)
+ snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
+ "%+d#0x%lx", insn->off, address);
+ else
+ snprintf(dd->scratch_buff, sizeof(dd->scratch_buff),
+ "%+d", insn->off);
return dd->scratch_buff;
}
@@ -200,14 +204,20 @@ static const char *print_call(void *private_data,
const struct bpf_insn *insn)
{
struct dump_data *dd = private_data;
- unsigned long address = dd->address_call_base + insn->imm;
- struct kernel_sym *sym;
+ unsigned long address = 0;
+ struct kernel_sym *sym = NULL;
- sym = kernel_syms_search(dd, address);
- if (insn->src_reg == BPF_PSEUDO_CALL)
+ if (insn->src_reg == BPF_PSEUDO_CALL) {
+ if (dd->nr_jited_funcs) {
+ address = dd->jited_funcs[insn->imm];
+ sym = kernel_syms_search(dd, address);
+ }
return print_call_pcrel(dd, sym, address, insn);
- else
+ } else {
+ address = dd->address_call_base + insn->imm;
+ sym = kernel_syms_search(dd, address);
return print_call_helper(dd, sym, address);
+ }
}
static const char *print_imm(void *private_data,
diff --git a/tools/bpf/bpftool/xlated_dumper.h b/tools/bpf/bpftool/xlated_dumper.h
index b34affa7ef2d..6afc03a5fbad 100644
--- a/tools/bpf/bpftool/xlated_dumper.h
+++ b/tools/bpf/bpftool/xlated_dumper.h
@@ -47,6 +47,8 @@ struct kernel_sym {
struct dump_data {
unsigned long address_call_base;
+ unsigned long *jited_funcs;
+ unsigned int nr_jited_funcs;
struct kernel_sym *sym_mapping;
__u32 sym_count;
char scratch_buff[SYM_MAX_NAME + 8];
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf v3 4/5] tools: bpf: sync bpf uapi header
From: Sandipan Das @ 2018-05-14 11:51 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
In-Reply-To: <20180514115118.8149-1-sandipan@linux.vnet.ibm.com>
Syncing the bpf.h uapi header with tools so that struct
bpf_prog_info has the new fields for storing the kernel
symbol addresses for the JITed functions in a program.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
tools/include/uapi/linux/bpf.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 83a95ae388dd..98857dc3469a 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -2107,6 +2107,8 @@ struct bpf_prog_info {
__u32 xlated_prog_len;
__aligned_u64 jited_prog_insns;
__aligned_u64 xlated_prog_insns;
+ __aligned_u64 jited_funcs;
+ __u32 nr_jited_funcs;
__u64 load_time; /* ns since boottime */
__u32 created_by_uid;
__u32 nr_map_ids;
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf v3 3/5] bpf: get JITed function addresses via syscall
From: Sandipan Das @ 2018-05-14 11:51 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
In-Reply-To: <20180514115118.8149-1-sandipan@linux.vnet.ibm.com>
This adds new two new fields to struct bpf_prog_info. For
multi-function programs, these fields can be used to pass
a list of kernel symbol addresses for all functions in a
given program and to userspace using the bpf system call
with the BPF_OBJ_GET_INFO_BY_FD command.
When bpf_jit_kallsyms is enabled, we can get the address
of the corresponding kernel symbol for a callee function
and resolve the symbol's name. The address is determined
by adding the value of the call instruction's imm field
to __bpf_call_base. This offset gets assigned to the imm
field by the verifier.
For some architectures, such as powerpc64, the imm field
is not large enough to hold this offset.
We resolve this by:
[1] Assigning the subprog id to the imm field of a call
instruction in the verifier instead of the offset of
the callee's symbol's address from __bpf_call_base.
[2] Determining the address of a callee's corresponding
symbol by using the imm field as an index for the
list of function addresses now available from the
program info.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
include/uapi/linux/bpf.h | 2 ++
kernel/bpf/syscall.c | 18 ++++++++++++++++++
kernel/bpf/verifier.c | 7 +------
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 93d5a4eeec2a..b9c9c7690337 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2108,6 +2108,8 @@ struct bpf_prog_info {
__u32 xlated_prog_len;
__aligned_u64 jited_prog_insns;
__aligned_u64 xlated_prog_insns;
+ __aligned_u64 jited_funcs;
+ __u32 nr_jited_funcs;
__u64 load_time; /* ns since boottime */
__u32 created_by_uid;
__u32 nr_map_ids;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 9b87198deea2..600da849233d 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1924,6 +1924,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
if (!capable(CAP_SYS_ADMIN)) {
info.jited_prog_len = 0;
info.xlated_prog_len = 0;
+ info.nr_jited_funcs = 0;
goto done;
}
@@ -1972,6 +1973,23 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
}
}
+ ulen = info.nr_jited_funcs;
+ info.nr_jited_funcs = prog->aux->func_cnt;
+ if (info.nr_jited_funcs && ulen) {
+ u64 __user *user_jited_funcs = u64_to_user_ptr(info.jited_funcs);
+ u32 i;
+
+ /* copy the start addresses of the JITed images for all
+ * functions
+ */
+ ulen = min_t(u32, info.nr_jited_funcs, ulen);
+ for (i = 0; i < ulen; i++) {
+ if (put_user((u64) prog->aux->func[i]->bpf_func & PAGE_MASK,
+ &user_jited_funcs[i]))
+ return -EFAULT;
+ }
+ }
+
done:
if (copy_to_user(uinfo, &info, info_len) ||
put_user(info_len, &uattr->info.info_len))
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index aa76879f4fd1..fc864eb3e29d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5416,17 +5416,12 @@ static int jit_subprogs(struct bpf_verifier_env *env)
* later look the same as if they were interpreted only.
*/
for (i = 0, insn = prog->insnsi; i < prog->len; i++, insn++) {
- unsigned long addr;
-
if (insn->code != (BPF_JMP | BPF_CALL) ||
insn->src_reg != BPF_PSEUDO_CALL)
continue;
insn->off = env->insn_aux_data[i].call_imm;
subprog = find_subprog(env, i + insn->off + 1);
- addr = (unsigned long)func[subprog]->bpf_func;
- addr &= PAGE_MASK;
- insn->imm = (u64 (*)(u64, u64, u64, u64, u64))
- addr - __bpf_call_base;
+ insn->imm = subprog;
}
prog->jited = 1;
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf v3 2/5] bpf: powerpc64: add JIT support for multi-function programs
From: Sandipan Das @ 2018-05-14 11:51 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
In-Reply-To: <20180514115118.8149-1-sandipan@linux.vnet.ibm.com>
This adds support for bpf-to-bpf function calls in the powerpc64
JIT compiler. The JIT compiler converts the bpf call instructions
to native branch instructions. After a round of the usual passes,
the start addresses of the JITed images for the callee functions
are known. Finally, to fixup the branch target addresses, we need
to perform an extra pass.
Because of the address range in which JITed images are allocated
on powerpc64, the offsets of the start addresses of these images
from __bpf_call_base are as large as 64 bits. So, for a function
call, we cannot use the imm field of the instruction to determine
the callee's address. Instead, we use the alternative method of
getting it from the list of function addresses in the auxillary
data of the caller by using the off field as an index.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
v3: Mention briefly about why the offsets are large.
v2: Use the off field of the instruction as an index for
aux->func to determine the start address of a callee
function.
---
arch/powerpc/net/bpf_jit_comp64.c | 79 ++++++++++++++++++++++++++++++++++-----
1 file changed, 69 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 1bdb1aff0619..25939892d8f7 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -256,7 +256,7 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
/* Assemble the body code between the prologue & epilogue */
static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *ctx,
- u32 *addrs)
+ u32 *addrs, bool extra_pass)
{
const struct bpf_insn *insn = fp->insnsi;
int flen = fp->len;
@@ -712,11 +712,23 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
break;
/*
- * Call kernel helper
+ * Call kernel helper or bpf function
*/
case BPF_JMP | BPF_CALL:
ctx->seen |= SEEN_FUNC;
- func = (u8 *) __bpf_call_base + imm;
+
+ /* bpf function call */
+ if (insn[i].src_reg == BPF_PSEUDO_CALL && extra_pass)
+ if (fp->aux->func && off < fp->aux->func_cnt)
+ /* use the subprog id from the off
+ * field to lookup the callee address
+ */
+ func = (u8 *) fp->aux->func[off]->bpf_func;
+ else
+ return -EINVAL;
+ /* kernel helper call */
+ else
+ func = (u8 *) __bpf_call_base + imm;
bpf_jit_emit_func_call(image, ctx, (u64)func);
@@ -864,6 +876,14 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
return 0;
}
+struct powerpc64_jit_data {
+ struct bpf_binary_header *header;
+ u32 *addrs;
+ u8 *image;
+ u32 proglen;
+ struct codegen_context ctx;
+};
+
struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
{
u32 proglen;
@@ -871,6 +891,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
u8 *image = NULL;
u32 *code_base;
u32 *addrs;
+ struct powerpc64_jit_data *jit_data;
struct codegen_context cgctx;
int pass;
int flen;
@@ -878,6 +899,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
struct bpf_prog *org_fp = fp;
struct bpf_prog *tmp_fp;
bool bpf_blinded = false;
+ bool extra_pass = false;
if (!fp->jit_requested)
return org_fp;
@@ -891,7 +913,28 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
fp = tmp_fp;
}
+ jit_data = fp->aux->jit_data;
+ if (!jit_data) {
+ jit_data = kzalloc(sizeof(*jit_data), GFP_KERNEL);
+ if (!jit_data) {
+ fp = org_fp;
+ goto out;
+ }
+ fp->aux->jit_data = jit_data;
+ }
+
flen = fp->len;
+ addrs = jit_data->addrs;
+ if (addrs) {
+ cgctx = jit_data->ctx;
+ image = jit_data->image;
+ bpf_hdr = jit_data->header;
+ proglen = jit_data->proglen;
+ alloclen = proglen + FUNCTION_DESCR_SIZE;
+ extra_pass = true;
+ goto skip_init_ctx;
+ }
+
addrs = kzalloc((flen+1) * sizeof(*addrs), GFP_KERNEL);
if (addrs == NULL) {
fp = org_fp;
@@ -904,10 +947,10 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
cgctx.stack_size = round_up(fp->aux->stack_depth, 16);
/* Scouting faux-generate pass 0 */
- if (bpf_jit_build_body(fp, 0, &cgctx, addrs)) {
+ if (bpf_jit_build_body(fp, 0, &cgctx, addrs, false)) {
/* We hit something illegal or unsupported. */
fp = org_fp;
- goto out;
+ goto out_addrs;
}
/*
@@ -925,9 +968,10 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
bpf_jit_fill_ill_insns);
if (!bpf_hdr) {
fp = org_fp;
- goto out;
+ goto out_addrs;
}
+skip_init_ctx:
code_base = (u32 *)(image + FUNCTION_DESCR_SIZE);
/* Code generation passes 1-2 */
@@ -935,7 +979,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
/* Now build the prologue, body code & epilogue for real. */
cgctx.idx = 0;
bpf_jit_build_prologue(code_base, &cgctx);
- bpf_jit_build_body(fp, code_base, &cgctx, addrs);
+ bpf_jit_build_body(fp, code_base, &cgctx, addrs, extra_pass);
bpf_jit_build_epilogue(code_base, &cgctx);
if (bpf_jit_enable > 1)
@@ -956,15 +1000,30 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
((u64 *)image)[1] = local_paca->kernel_toc;
#endif
+ bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+
+ if (!fp->is_func || extra_pass) {
+ bpf_jit_binary_lock_ro(bpf_hdr);
+ } else {
+ jit_data->addrs = addrs;
+ jit_data->ctx = cgctx;
+ jit_data->proglen = proglen;
+ jit_data->image = image;
+ jit_data->header = bpf_hdr;
+ }
+
fp->bpf_func = (void *)image;
fp->jited = 1;
fp->jited_len = alloclen;
- bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+ if (!fp->is_func || extra_pass) {
+out_addrs:
+ kfree(addrs);
+ kfree(jit_data);
+ fp->aux->jit_data = NULL;
+ }
out:
- kfree(addrs);
-
if (bpf_blinded)
bpf_jit_prog_release_other(fp, fp == org_fp ? tmp_fp : org_fp);
--
2.14.3
^ permalink raw reply related
* [RFC][PATCH bpf v3 1/5] bpf: allow 64-bit offsets for bpf function calls
From: Sandipan Das @ 2018-05-14 11:51 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linuxppc-dev, mpe, naveen.n.rao
The imm field of a bpf instruction is a signed 32-bit integer.
For JIT bpf-to-bpf function calls, it stores the offset of the
start address of the callee's JITed image from __bpf_call_base.
For some architectures, such as powerpc64, this offset may be
as large as 64 bits and cannot be accomodated in the imm field
without truncation.
We resolve this by:
[1] Additionally using the auxillary data of each function to
keep a list of start addresses of the JITed images for all
functions determined by the verifier.
[2] Retaining the subprog id inside the off field of the call
instructions and using it to index into the list mentioned
above and lookup the callee's address.
To make sure that the existing JIT compilers continue to work
without requiring changes, we keep the imm field as it is.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
v3: Rephrase commit message to explain solution in a point-
wise manner.
v2: Make aux->func point to the list of functions determined
by the verifier rather than allocating a separate callee
list for each function.
---
kernel/bpf/verifier.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d5e1a6c4165d..aa76879f4fd1 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5373,11 +5373,24 @@ static int jit_subprogs(struct bpf_verifier_env *env)
insn->src_reg != BPF_PSEUDO_CALL)
continue;
subprog = insn->off;
- insn->off = 0;
insn->imm = (u64 (*)(u64, u64, u64, u64, u64))
func[subprog]->bpf_func -
__bpf_call_base;
}
+
+ /* we use the aux data to keep a list of the start addresses
+ * of the JITed images for each function in the program
+ *
+ * for some architectures, such as powerpc64, the imm field
+ * might not be large enough to hold the offset of the start
+ * address of the callee's JITed image from __bpf_call_base
+ *
+ * in such cases, we can lookup the start address of a callee
+ * by using its subprog id, available from the off field of
+ * the call instruction, as an index for this list
+ */
+ func[i]->aux->func = func;
+ func[i]->aux->func_cnt = env->subprog_cnt + 1;
}
for (i = 0; i < env->subprog_cnt; i++) {
old_bpf_func = func[i]->bpf_func;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
From: Greg KH @ 2018-05-14 11:24 UTC (permalink / raw)
To: Nipun Gupta
Cc: robin.murphy, will.deacon, robh+dt, robh, mark.rutland,
catalin.marinas, hch, joro, m.szyprowski, shawnguo, frowand.list,
bhelgaas, iommu, linux-kernel, devicetree, linux-arm-kernel,
linuxppc-dev, linux-pci, bharat.bhushan, stuyoder,
laurentiu.tudor, leoyang.li
In-Reply-To: <1525069641-8523-6-git-send-email-nipun.gupta@nxp.com>
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
I can't take patches without any changelog text at all, sorry. Please
fix up and resend.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines
From: Michael Ellerman @ 2018-05-14 11:18 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linuxppc-dev, linux-kernel, mhcerri, pfsmorigo
In-Reply-To: <20180511161913.nr7woksn2jejipzm@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote:
>> In the vmx AES init routines we do a printk(KERN_INFO ...) to report
>> the fallback implementation we're using.
>>
>> However with a slow console this can significantly affect the speed of
>> crypto operations. Using 'cryptsetup benchmark' the removal of the
>> printk() leads to a ~5x speedup for aes-cbc decryption.
>>
>> So remove them.
>>
>> Fixes: 8676590a1593 ("crypto: vmx - Adding AES routines for VMX module")
>> Fixes: 8c755ace357c ("crypto: vmx - Adding CBC routines for VMX module")
>> Fixes: 4f7f60d312b3 ("crypto: vmx - Adding CTR routines for VMX module")
>> Fixes: cc333cd68dfa ("crypto: vmx - Adding GHASH routines for VMX module")
>> Cc: stable@vger.kernel.org # v4.1+
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> ---
>> drivers/crypto/vmx/aes.c | 2 --
>> drivers/crypto/vmx/aes_cbc.c | 3 ---
>> drivers/crypto/vmx/aes_ctr.c | 2 --
>> drivers/crypto/vmx/ghash.c | 2 --
>> 4 files changed, 9 deletions(-)
>
> Patch applied. Thanks.
Thanks.
>> If this is the wrong fix please let me know, I'm not a crypto expert.
>>
>> What we see is 'cryptsetup benchmark' causing thousands of these printks() to
>> happen. The call trace is something like:
>>
>> [c000001e47867a60] [c0000000009cf6b4] p8_aes_cbc_init+0x74/0xf0
>> [c000001e47867ae0] [c000000000551a80] __crypto_alloc_tfm+0x1d0/0x2c0
>> [c000001e47867b20] [c00000000055aea4] crypto_skcipher_init_tfm+0x124/0x280
>> [c000001e47867b60] [c00000000055138c] crypto_create_tfm+0x9c/0x1a0
>> [c000001e47867ba0] [c000000000552220] crypto_alloc_tfm+0xa0/0x140
>> [c000001e47867c00] [c00000000055b168] crypto_alloc_skcipher+0x48/0x70
>> [c000001e47867c40] [c00000000057af28] skcipher_bind+0x38/0x50
>> [c000001e47867c80] [c00000000057a07c] alg_bind+0xbc/0x220
>> [c000001e47867d10] [c000000000a016a0] __sys_bind+0x90/0x100
>> [c000001e47867df0] [c000000000a01750] sys_bind+0x40/0x60
>> [c000001e47867e30] [c00000000000b320] system_call+0x58/0x6c
>>
>>
>> Is it normal for init to be called on every system call?
>
> This is the tfm init function, so yes it is called every time
> you allocate a tfm.
OK thanks. So we just shouldn't be printk'ing in there in the non-error
path, good to know.
cheers
^ permalink raw reply
* Re: [PATCH v4 1/2] cxl: Set the PBCQ Tunnel BAR register when enabling capi mode
From: Michael Ellerman @ 2018-05-14 10:51 UTC (permalink / raw)
To: stewart; +Cc: fbarrat, clombard, Philippe Bergheaud, benh
In-Reply-To: <20180514082736.3699-1-felix@linux.ibm.com>
Philippe Bergheaud <felix@linux.ibm.com> writes:
> Skiboot used to set the default Tunnel BAR register value when capi mode
> was enabled. This approach was ok for the cxl driver, but prevented other
> drivers from choosing different values.
>
> Skiboot versions > 5.11 will not set the default value any longer. This
> patch modifies the cxl driver to set/reset the Tunnel BAR register when
> entering/exiting the cxl mode, with pnv_pci_set_tunnel_bar().
>
> That should work with old skiboot (since we are re-writing the value
> already set) and new skiboot.
But doesn't that mean new skiboot can't boot any old kernel? That seems
undesirable.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Michael Ellerman @ 2018-05-14 10:49 UTC (permalink / raw)
To: Anju T Sudhakar, Balbir Singh
Cc: Madhavan Srinivasan,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), ppaidipe
In-Reply-To: <e36d5e9e-0d93-0641-061e-730444f1c621@linux.vnet.ibm.com>
Anju T Sudhakar <anju@linux.vnet.ibm.com> writes:
> On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote:
>> On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar
>> <anju@linux.vnet.ibm.com> wrote:
>>> Currently memory is allocated for core-imc based on cpu_present_mask, which has
>>> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
>>> as as array index to access the memory.
>>> So in a system with guarded cores, since allocation happens based on
>>> cpu_present_mask, (cpu number / threads per core) bounds the index and leads
>>> to memory overflow.
>>>
>>> The issue is exposed in a guard test.
>>> The guard test will make some CPU's as un-available to the system during boot
>>> time as well as at runtime. So when the cpu is unavailable to the system during
>>> boot time, the memory allocation happens depending on the number of available
>>> cpus. And when we access the memory using (cpu number / threads per core) as the
>>> index the system crashes due to memory overflow.
>>>
>>> Allocating memory for core-imc based on cpu_possible_mask, which has
>>> bit 'cpu' set iff cpu is populatable, will fix this issue.
>>>
>>> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
>>> ---
>>> arch/powerpc/perf/imc-pmu.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> The changelog does not clearly call out the confusion between present
>> and possible.
>> Guarded CPUs are possible but not present, so it blows a hole when we assume the
>> max length of our allocation is driven by our max present cpus, where
>> as one of the cpus
>> might be online and be beyond the max present cpus, due to the hole..
>>
>> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
>
> Thanks for the review.
> OK. I will update the commit message here.
Yeah please do. "Guarded" CPUs is also not a well understand term, so
please explain what that means for people who don't know.
cheers
^ permalink raw reply
* Re: [PATCH 2/3] hwmon: (ibmpowernv): Add support to read 64 bit sensors
From: Guenter Roeck @ 2018-05-14 10:35 UTC (permalink / raw)
To: Michael Ellerman, Shilpasri G Bhat
Cc: linux-kernel, linuxppc-dev, linux-hwmon, benh, paulus, jdelvare,
stewart
In-Reply-To: <87y3gmpv8t.fsf@concordia.ellerman.id.au>
On 05/14/2018 12:11 AM, Michael Ellerman wrote:
> Guenter Roeck <linux@roeck-us.net> writes:
>
>> On Mon, May 07, 2018 at 03:55:37PM +0530, Shilpasri G Bhat wrote:
>>> The firmware has supported for reading sensor values of size u32.
>>> This patch adds support to use newer firmware functions which allows
>>> to read the sensors of size u64.
>>>
>>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
>>
>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>
>> I won't apply for the time being since it depends on patch 1/3 which is
>> outside hwmon.
>
> Do you mind if I take the series via the powerpc tree?
>
Fine with me.
Guenter
^ permalink raw reply
* [PATCH kernel v3] powerpc/ioda: Use ibm, supported-tce-sizes for IOMMU page size mask
From: Alexey Kardashevskiy @ 2018-05-14 9:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, David Gibson, Michael Ellerman,
Russell Currey
At the moment we assume that IODA2 and newer PHBs can always do 4K/64K/16M
IOMMU pages, however this is not the case for POWER9 and now skiboot
advertises the supported sizes via the device so we use that instead
of hard coding the mask.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v3:
* use modern device tree accessors
v2:
* added quirk for POWER8 to advertise 16M if skiboot has not provided info
---
arch/powerpc/platforms/powernv/pci-ioda.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3f9c69d..9731098 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -2910,6 +2910,34 @@ static void pnv_pci_ioda2_table_free_pages(struct iommu_table *tbl)
tbl->it_indirect_levels);
}
+static unsigned long pnv_ioda_parse_tce_sizes(struct pnv_phb *phb)
+{
+ struct pci_controller *hose = phb->hose;
+ struct device_node *dn = hose->dn;
+ unsigned long mask = 0;
+ int i, rc, count;
+ u32 val;
+
+ count = of_property_count_u32_elems(dn, "ibm,supported-tce-sizes");
+ if (count <= 0) {
+ mask = SZ_4K | SZ_64K;
+ /* Add 16M for POWER8 by default */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S) &&
+ !cpu_has_feature(CPU_FTR_ARCH_300))
+ mask |= SZ_16M;
+ return mask;
+ }
+
+ for (i = 0; i < count; i++) {
+ rc = of_property_read_u32_index(dn, "ibm,supported-tce-sizes",
+ i, &val);
+ if (rc == 0)
+ mask |= 1ULL << val;
+ }
+
+ return mask;
+}
+
static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
{
@@ -2934,7 +2962,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
pe->table_group.max_dynamic_windows_supported =
IOMMU_TABLE_GROUP_MAX_TABLES;
pe->table_group.max_levels = POWERNV_IOMMU_MAX_LEVELS;
- pe->table_group.pgsizes = SZ_4K | SZ_64K | SZ_16M;
+ pe->table_group.pgsizes = pnv_ioda_parse_tce_sizes(phb);
#ifdef CONFIG_IOMMU_API
pe->table_group.ops = &pnv_pci_ioda2_ops;
#endif
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] powerpc/cpu: nr_cpu_ids should be aligned on threads_per_core
From: kbuild test robot @ 2018-05-14 9:22 UTC (permalink / raw)
To: Pingfan Liu; +Cc: kbuild-all, linuxppc-dev
In-Reply-To: <1526278438-10519-1-git-send-email-kernelfans@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4999 bytes --]
Hi Pingfan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.17-rc5 next-20180511]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Pingfan-Liu/powerpc-cpu-nr_cpu_ids-should-be-aligned-on-threads_per_core/20180514-141629
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allnoconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.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
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/kernel/prom.c: In function 'early_init_dt_scan_cpus':
>> arch/powerpc/kernel/prom.c:370:14: error: lvalue required as left operand of assignment
nr_cpu_ids = nr_cpus_aligned;
^
vim +370 arch/powerpc/kernel/prom.c
306
307 static int __init early_init_dt_scan_cpus(unsigned long node,
308 const char *uname, int depth,
309 void *data)
310 {
311 const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
312 const __be32 *prop;
313 const __be32 *intserv;
314 int i, nthreads;
315 int len;
316 int found = -1;
317 int found_thread = 0;
318 unsigned int nr_cpus_aligned;
319
320 /* We are scanning "cpu" nodes only */
321 if (type == NULL || strcmp(type, "cpu") != 0)
322 return 0;
323
324 /* Get physical cpuid */
325 intserv = of_get_flat_dt_prop(node, "ibm,ppc-interrupt-server#s", &len);
326 if (!intserv)
327 intserv = of_get_flat_dt_prop(node, "reg", &len);
328
329 nthreads = len / sizeof(int);
330
331 /*
332 * Now see if any of these threads match our boot cpu.
333 * NOTE: This must match the parsing done in smp_setup_cpu_maps.
334 */
335 for (i = 0; i < nthreads; i++) {
336 /*
337 * version 2 of the kexec param format adds the phys cpuid of
338 * booted proc.
339 */
340 if (fdt_version(initial_boot_params) >= 2) {
341 if (be32_to_cpu(intserv[i]) ==
342 fdt_boot_cpuid_phys(initial_boot_params)) {
343 found = boot_cpu_count;
344 found_thread = i;
345 }
346 } else {
347 /*
348 * Check if it's the boot-cpu, set it's hw index now,
349 * unfortunately this format did not support booting
350 * off secondary threads.
351 */
352 if (of_get_flat_dt_prop(node,
353 "linux,boot-cpu", NULL) != NULL)
354 found = boot_cpu_count;
355 }
356 #ifdef CONFIG_SMP
357 /* logical cpu id is always 0 on UP kernels */
358 boot_cpu_count++;
359 #endif
360 }
361
362 /* Not the boot CPU */
363 if (found < 0)
364 return 0;
365 /* to work around p8 subcore mode */
366 nr_cpus_aligned = _ALIGN_UP(nr_cpu_ids, nthreads);
367 if (nr_cpus_aligned != nr_cpu_ids) {
368 pr_info("nr_cpus is forced to align up on threads_per_core,"
369 "from %u to %u\n", nr_cpu_ids, nr_cpus_aligned);
> 370 nr_cpu_ids = nr_cpus_aligned;
371 }
372 DBG("boot cpu: logical %d physical %d\n", found,
373 be32_to_cpu(intserv[found_thread]));
374 boot_cpuid = found;
375
376 /*
377 * PAPR defines "logical" PVR values for cpus that
378 * meet various levels of the architecture:
379 * 0x0f000001 Architecture version 2.04
380 * 0x0f000002 Architecture version 2.05
381 * If the cpu-version property in the cpu node contains
382 * such a value, we call identify_cpu again with the
383 * logical PVR value in order to use the cpu feature
384 * bits appropriate for the architecture level.
385 *
386 * A POWER6 partition in "POWER6 architected" mode
387 * uses the 0x0f000002 PVR value; in POWER5+ mode
388 * it uses 0x0f000001.
389 *
390 * If we're using device tree CPU feature discovery then we don't
391 * support the cpu-version property, and it's the responsibility of the
392 * firmware/hypervisor to provide the correct feature set for the
393 * architecture level via the ibm,powerpc-cpu-features binding.
394 */
395 if (!dt_cpu_ftrs_in_use()) {
396 prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
397 if (prop && (be32_to_cpup(prop) & 0xff000000) == 0x0f000000)
398 identify_cpu(0, be32_to_cpup(prop));
399
400 check_cpu_feature_properties(node);
401 check_cpu_pa_features(node);
402 }
403
404 identical_pvr_fixup(node);
405 init_mmu_slb_size(node);
406
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 5507 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Anju T Sudhakar @ 2018-05-14 8:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: mpe, maddy, ppaidipe
In-Reply-To: <1526046222-17842-1-git-send-email-anju@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
On Friday 11 May 2018 07:13 PM, Anju T Sudhakar wrote:
> Currently memory is allocated for core-imc based on cpu_present_mask, which has
> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
> as as array index to access the memory.
> So in a system with guarded cores, since allocation happens based on
> cpu_present_mask, (cpu number / threads per core) bounds the index and leads
> to memory overflow.
>
> The issue is exposed in a guard test.
> The guard test will make some CPU's as un-available to the system during boot
> time as well as at runtime. So when the cpu is unavailable to the system during
> boot time, the memory allocation happens depending on the number of available
> cpus. And when we access the memory using (cpu number / threads per core) as the
> index the system crashes due to memory overflow.
>
> Allocating memory for core-imc based on cpu_possible_mask, which has
> bit 'cpu' set iff cpu is populatable, will fix this issue.
>
> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> # v4.14 +
> ---
> arch/powerpc/perf/imc-pmu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
> index d7532e7..75fb23c 100644
> --- a/arch/powerpc/perf/imc-pmu.c
> +++ b/arch/powerpc/perf/imc-pmu.c
> @@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
>
> static void cleanup_all_core_imc_memory(void)
> {
> - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
> + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
> struct imc_mem_info *ptr = core_imc_pmu->mem_info;
> int size = core_imc_pmu->counter_mem_size;
>
> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct device_node *parent,
> if (!pmu_ptr->pmu.name)
> return -ENOMEM;
>
> - nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
> + nr_cores = DIV_ROUND_UP(num_possible_cpus(), threads_per_core);
> pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct imc_mem_info),
> GFP_KERNEL);
>
[-- Attachment #2: Type: text/html, Size: 2941 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Anju T Sudhakar @ 2018-05-14 8:32 UTC (permalink / raw)
To: Balbir Singh
Cc: open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
Madhavan Srinivasan, ppaidipe
In-Reply-To: <CAKTCnzn1QmirDJNOJ5hVB0wKE-wpVLePivZocZ8g0e+sA4O7Wg@mail.gmail.com>
Hi,
On Saturday 12 May 2018 06:05 AM, Balbir Singh wrote:
> On Fri, May 11, 2018 at 11:43 PM, Anju T Sudhakar
> <anju@linux.vnet.ibm.com> wrote:
>> Currently memory is allocated for core-imc based on cpu_present_mask, which has
>> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
>> as as array index to access the memory.
>> So in a system with guarded cores, since allocation happens based on
>> cpu_present_mask, (cpu number / threads per core) bounds the index and leads
>> to memory overflow.
>>
>> The issue is exposed in a guard test.
>> The guard test will make some CPU's as un-available to the system during boot
>> time as well as at runtime. So when the cpu is unavailable to the system during
>> boot time, the memory allocation happens depending on the number of available
>> cpus. And when we access the memory using (cpu number / threads per core) as the
>> index the system crashes due to memory overflow.
>>
>> Allocating memory for core-imc based on cpu_possible_mask, which has
>> bit 'cpu' set iff cpu is populatable, will fix this issue.
>>
>> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/perf/imc-pmu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
> The changelog does not clearly call out the confusion between present
> and possible.
> Guarded CPUs are possible but not present, so it blows a hole when we assume the
> max length of our allocation is driven by our max present cpus, where
> as one of the cpus
> might be online and be beyond the max present cpus, due to the hole..
>
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
>
> Balbir Singh.
>
Thanks for the review.
OK. I will update the commit message here.
Regards,
Anju
^ permalink raw reply
* [PATCH v4 2/2] cxl: Report the tunneled operations status
From: Philippe Bergheaud @ 2018-05-14 8:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: fbarrat, clombard, benh, Philippe Bergheaud
In-Reply-To: <20180514082736.3699-1-felix@linux.ibm.com>
Failure to synchronize the tunneled operations does not prevent
the initialization of the cxl card. This patch reports the tunneled
operations status via /sys.
Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
---
v3: Added this patch to report the tunneled operations status.
v4: Updated Documentation/ABI/testing/sysfs-class-cxl.
---
Documentation/ABI/testing/sysfs-class-cxl | 8 ++++++++
drivers/misc/cxl/cxl.h | 1 +
drivers/misc/cxl/pci.c | 7 ++++++-
drivers/misc/cxl/sysfs.c | 10 ++++++++++
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
index 640f65e79ef1..8e69345c37cc 100644
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -244,3 +244,11 @@ Description: read only
Returns 1 if the psl timebase register is synchronized
with the core timebase register, 0 otherwise.
Users: https://github.com/ibm-capi/libcxl
+
+What: /sys/class/cxl/<card>/tunneled_ops_supported
+Date: May 2018
+Contact: linuxppc-dev@lists.ozlabs.org
+Description: read only
+ Returns 1 if tunneled operations are supported in capi mode,
+ 0 otherwise.
+Users: https://github.com/ibm-capi/libcxl
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index a4c9c8297a6d..918d4fb742d1 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -717,6 +717,7 @@ struct cxl {
bool perst_select_user;
bool perst_same_image;
bool psl_timebase_synced;
+ bool tunneled_ops_supported;
/*
* number of contexts mapped on to this card. Possible values are:
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 355c789406f7..008f50a0c465 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1742,9 +1742,14 @@ static int cxl_configure_adapter(struct cxl *adapter, struct pci_dev *dev)
/* Required for devices using CAPP DMA mode, harmless for others */
pci_set_master(dev);
- if (cxl_is_power9())
+ adapter->tunneled_ops_supported = false;
+
+ if (cxl_is_power9()) {
if (pnv_pci_set_tunnel_bar(dev, 0x00020000E0000000ull, 1))
dev_info(&dev->dev, "Tunneled operations unsupported\n");
+ else
+ adapter->tunneled_ops_supported = true;
+ }
if ((rc = pnv_phb_to_cxl_mode(dev, adapter->native->sl_ops->capi_mode)))
goto err;
diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
index 95285b7f636f..4b5a4c5d3c01 100644
--- a/drivers/misc/cxl/sysfs.c
+++ b/drivers/misc/cxl/sysfs.c
@@ -78,6 +78,15 @@ static ssize_t psl_timebase_synced_show(struct device *device,
return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
}
+static ssize_t tunneled_ops_supported_show(struct device *device,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cxl *adapter = to_cxl_adapter(device);
+
+ return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->tunneled_ops_supported);
+}
+
static ssize_t reset_adapter_store(struct device *device,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -183,6 +192,7 @@ static struct device_attribute adapter_attrs[] = {
__ATTR_RO(base_image),
__ATTR_RO(image_loaded),
__ATTR_RO(psl_timebase_synced),
+ __ATTR_RO(tunneled_ops_supported),
__ATTR_RW(load_image_on_perst),
__ATTR_RW(perst_reloads_same_image),
__ATTR(reset, S_IWUSR, NULL, reset_adapter_store),
--
2.16.3
^ permalink raw reply related
* [PATCH v4 1/2] cxl: Set the PBCQ Tunnel BAR register when enabling capi mode
From: Philippe Bergheaud @ 2018-05-14 8:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: fbarrat, clombard, benh, Philippe Bergheaud
Skiboot used to set the default Tunnel BAR register value when capi mode
was enabled. This approach was ok for the cxl driver, but prevented other
drivers from choosing different values.
Skiboot versions > 5.11 will not set the default value any longer. This
patch modifies the cxl driver to set/reset the Tunnel BAR register when
entering/exiting the cxl mode, with pnv_pci_set_tunnel_bar().
That should work with old skiboot (since we are re-writing the value
already set) and new skiboot.
Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
Reviewed-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
---
v2: Restrict tunnel bar setting to power9.
Do not fail cxl_configure_adapter() on tunnel bar setting error.
Log an info message instead, and continue configuring capi mode.
v3,v4: No change.
---
drivers/misc/cxl/pci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 83f1d08058fc..355c789406f7 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -1742,6 +1742,10 @@ static int cxl_configure_adapter(struct cxl *adapter, struct pci_dev *dev)
/* Required for devices using CAPP DMA mode, harmless for others */
pci_set_master(dev);
+ if (cxl_is_power9())
+ if (pnv_pci_set_tunnel_bar(dev, 0x00020000E0000000ull, 1))
+ dev_info(&dev->dev, "Tunneled operations unsupported\n");
+
if ((rc = pnv_phb_to_cxl_mode(dev, adapter->native->sl_ops->capi_mode)))
goto err;
@@ -1768,6 +1772,8 @@ static void cxl_deconfigure_adapter(struct cxl *adapter)
{
struct pci_dev *pdev = to_pci_dev(adapter->dev.parent);
+ if (cxl_is_power9())
+ pnv_pci_set_tunnel_bar(pdev, 0x00020000E0000000ull, 0);
cxl_native_release_psl_err_irq(adapter);
cxl_unmap_adapter_regs(adapter);
--
2.16.3
^ permalink raw reply related
* RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
From: Yinbo Zhu @ 2018-05-14 7:47 UTC (permalink / raw)
To: Leo Li, Rob Herring, Mark Rutland, Catalin Marinas ),
Will Deacon ), Lorenzo Pieralisi )
Cc: Xiaobo Xie, Ran Wang, Daniel Lezcano, Thomas Gleixner, Shawn Guo,
Madalin-cristian Bucur, Z.q. Hou, Jerry Huang, M.h. Lian,
Qiang Zhao, Fabio Estevam, Jiaheng Fan, Po Liu, Nipun Gupta,
Horia Geantă, Priyanka Jain, Sumit Garg, costi,
Bogdan Purcareata, open list:CLOCKSOURCE, CLOCKEVENT DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel@lists.infradead.org,
open list:FREESCALE SOC DRIVERS, Andy Tang, Ying Zhang
In-Reply-To: <AM4PR0401MB16995DFED0376ACE0DD5E7A78F9F0@AM4PR0401MB1699.eurprd04.prod.outlook.com>
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMZW8gTGkgDQpTZW50OiAyMDE4
5bm0NeaciDEy5pelIDE6MDANClRvOiBZaW5ibyBaaHUgPHlpbmJvLnpodUBueHAuY29tPjsgWWlu
Ym8gWmh1IDx5aW5iby56aHVAbnhwLmNvbT47IFJvYiBIZXJyaW5nIDxyb2JoK2R0QGtlcm5lbC5v
cmc+OyBNYXJrIFJ1dGxhbmQgPG1hcmsucnV0bGFuZEBhcm0uY29tPjsgQ2F0YWxpbiBNYXJpbmFz
ICkgPGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tPjsgV2lsbCBEZWFjb24gKSA8d2lsbC5kZWFjb25A
YXJtLmNvbT47IExvcmVuem8gUGllcmFsaXNpICkgPGxvcmVuem8ucGllcmFsaXNpQGFybS5jb20+
DQpDYzogWGlhb2JvIFhpZSA8eGlhb2JvLnhpZUBueHAuY29tPjsgUmFuIFdhbmcgPHJhbi53YW5n
XzFAbnhwLmNvbT47IERhbmllbCBMZXpjYW5vIDxkYW5pZWwubGV6Y2Fub0BsaW5hcm8ub3JnPjsg
VGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+OyBTaGF3biBHdW8gPHNoYXduZ3Vv
QGtlcm5lbC5vcmc+OyBNYWRhbGluLWNyaXN0aWFuIEJ1Y3VyIDxtYWRhbGluLmJ1Y3VyQG54cC5j
b20+OyBaLnEuIEhvdSA8emhpcWlhbmcuaG91QG54cC5jb20+OyBKZXJyeSBIdWFuZyA8amVycnku
aHVhbmdAbnhwLmNvbT47IE0uaC4gTGlhbiA8bWluZ2h1YW4ubGlhbkBueHAuY29tPjsgUWlhbmcg
WmhhbyA8cWlhbmcuemhhb0BueHAuY29tPjsgRmFiaW8gRXN0ZXZhbSA8ZmFiaW8uZXN0ZXZhbUBu
eHAuY29tPjsgSmlhaGVuZyBGYW4gPGppYWhlbmcuZmFuQG54cC5jb20+OyBQbyBMaXUgPHBvLmxp
dUBueHAuY29tPjsgTmlwdW4gR3VwdGEgPG5pcHVuLmd1cHRhQG54cC5jb20+OyBIb3JpYSBHZWFu
dMSDIDxob3JpYS5nZWFudGFAbnhwLmNvbT47IFByaXlhbmthIEphaW4gPHByaXlhbmthLmphaW5A
bnhwLmNvbT47IFN1bWl0IEdhcmcgPHN1bWl0LmdhcmdAbnhwLmNvbT47IGNvc3RpIDxjb25zdGFu
dGluLnR1ZG9yQGZyZWVzY2FsZS5jb20+OyBCb2dkYW4gUHVyY2FyZWF0YSA8Ym9nZGFuLnB1cmNh
cmVhdGFAbnhwLmNvbT47IG9wZW4gbGlzdDpDTE9DS1NPVVJDRSwgQ0xPQ0tFVkVOVCBEUklWRVJT
IDxsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnPjsgb3BlbiBsaXN0Ok9QRU4gRklSTVdBUkUg
QU5EIEZMQVRURU5FRCBERVZJQ0UgVFJFRSBCSU5ESU5HUyA8ZGV2aWNldHJlZUB2Z2VyLmtlcm5l
bC5vcmc+OyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IG9wZW4gbGlzdDpG
UkVFU0NBTEUgU09DIERSSVZFUlMgPGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnPjsgQW5k
eSBUYW5nIDxhbmR5LnRhbmdAbnhwLmNvbT47IFlpbmcgWmhhbmcgPHlpbmcuemhhbmcyMjQ1NUBu
eHAuY29tPg0KU3ViamVjdDogUkU6IFtQQVRDSCAzLzldIHNvYzogZnNsOiBzZXQgcmNwbSBiaXQg
Zm9yIEZUTQ0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZaW5i
byBaaHUgW21haWx0bzp5aW5iby56aHVAbnhwLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE1heSAx
MCwgMjAxOCAxMDozNSBQTQ0KPiBUbzogWWluYm8gWmh1IDx5aW5iby56aHVAbnhwLmNvbT47IFJv
YiBIZXJyaW5nIDxyb2JoK2R0QGtlcm5lbC5vcmc+OyANCj4gTWFyayBSdXRsYW5kIDxtYXJrLnJ1
dGxhbmRAYXJtLmNvbT47IENhdGFsaW4gTWFyaW5hcyApIA0KPiA8Y2F0YWxpbi5tYXJpbmFzQGFy
bS5jb20+OyBXaWxsIERlYWNvbiApIDx3aWxsLmRlYWNvbkBhcm0uY29tPjsgDQo+IExvcmVuem8g
UGllcmFsaXNpICkgPGxvcmVuem8ucGllcmFsaXNpQGFybS5jb20+OyBMZW8gTGkgDQo+IDxsZW95
YW5nLmxpQG54cC5jb20+DQo+IENjOiBYaWFvYm8gWGllIDx4aWFvYm8ueGllQG54cC5jb20+OyBS
YW4gV2FuZyA8cmFuLndhbmdfMUBueHAuY29tPjsgDQo+IERhbmllbCBMZXpjYW5vIDxkYW5pZWwu
bGV6Y2Fub0BsaW5hcm8ub3JnPjsgVGhvbWFzIEdsZWl4bmVyIA0KPiA8dGdseEBsaW51dHJvbml4
LmRlPjsgU2hhd24gR3VvIDxzaGF3bmd1b0BrZXJuZWwub3JnPjsgDQo+IE1hZGFsaW4tY3Jpc3Rp
YW4gQnVjdXIgPG1hZGFsaW4uYnVjdXJAbnhwLmNvbT47IFoucS4gSG91IA0KPiA8emhpcWlhbmcu
aG91QG54cC5jb20+OyBKZXJyeSBIdWFuZyA8amVycnkuaHVhbmdAbnhwLmNvbT47IE0uaC4gTGlh
biANCj4gPG1pbmdodWFuLmxpYW5AbnhwLmNvbT47IFFpYW5nIFpoYW8gPHFpYW5nLnpoYW9Abnhw
LmNvbT47IEZhYmlvIA0KPiBFc3RldmFtIDxmYWJpby5lc3RldmFtQG54cC5jb20+OyBKaWFoZW5n
IEZhbiA8amlhaGVuZy5mYW5AbnhwLmNvbT47IFBvIA0KPiBMaXUgPHBvLmxpdUBueHAuY29tPjsg
TmlwdW4gR3VwdGEgPG5pcHVuLmd1cHRhQG54cC5jb20+OyBIb3JpYSBHZWFudMSDIA0KPiA8aG9y
aWEuZ2VhbnRhQG54cC5jb20+OyBQcml5YW5rYSBKYWluIDxwcml5YW5rYS5qYWluQG54cC5jb20+
OyBTdW1pdCANCj4gR2FyZyA8c3VtaXQuZ2FyZ0BueHAuY29tPjsgY29zdGkgPGNvbnN0YW50aW4u
dHVkb3JAZnJlZXNjYWxlLmNvbT47IA0KPiBCb2dkYW4gUHVyY2FyZWF0YSA8Ym9nZGFuLnB1cmNh
cmVhdGFAbnhwLmNvbT47IE1lbmcgWWkgDQo+IDxtZW5nLnlpQG54cC5jb20+OyBXYW5nIERvbmdz
aGVuZyA8ZG9uZ3NoZW5nLndhbmdAbnhwLmNvbT47IG9wZW4gDQo+IGxpc3Q6Q0xPQ0tTT1VSQ0Us
IENMT0NLRVZFTlQgRFJJVkVSUyA8bGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZz47IA0KPiBv
cGVuIGxpc3Q6T1BFTiBGSVJNV0FSRSBBTkQgRkxBVFRFTkVEIERFVklDRSBUUkVFIEJJTkRJTkdT
IA0KPiA8ZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc+OyBsaW51eC1hcm0ta2VybmVsQGxpc3Rz
LmluZnJhZGVhZC5vcmc7IA0KPiBvcGVuIGxpc3Q6RlJFRVNDQUxFIFNPQyBEUklWRVJTIDxsaW51
eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZz47IEFuZHkgDQo+IFRhbmcgPGFuZHkudGFuZ0BueHAu
Y29tPjsgWWluZyBaaGFuZyA8eWluZy56aGFuZzIyNDU1QG54cC5jb20+DQo+IFN1YmplY3Q6IFtQ
QVRDSCAzLzldIHNvYzogZnNsOiBzZXQgcmNwbSBiaXQgZm9yIEZUTQ0KPiANCj4gRnJvbTogWmhh
bmcgWWluZy0yMjQ1NSA8eWluZy56aGFuZzIyNDU1QG54cC5jb20+DQo+IA0KPiBTZXQgUkNQTSBm
b3IgRlRNIHdoZW4gdXNpbmcgRlRNIGFzIHdha2V1cCBzb3VyY2UuIEJlY2F1c2UgdGhlIFJDUE0g
DQo+IG1vZHVsZSBvZiBlYWNoIHBsYXRmb3JtIGhhcyBkaWZmZXJlbnQgYmlnLWVuZCBhbmQgbGl0
dGxlLWVuZCBtb2RlLCANCj4gdGhlcmUgbmVlZCB0byBzZXQgUkNQTSBkZXBlbmRpbmcgb24gdGhl
IHBsYXRmb3JtLg0KPiANCj4gU2lnbmVkLW9mZi1ieTogWmhhbmcgWWluZy0yMjQ1NSA8eWluZy56
aGFuZzIyNDU1QG54cC5jb20+DQo+IFNpZ25lZC1vZmYtYnk6IFlpbmJvIFpodSA8eWluYm8uemh1
QG54cC5jb20+DQo+IC0tLQ0KPiAgLi4uL2RldmljZXRyZWUvYmluZGluZ3MvdGltZXIvZnNsLGZ0
bS10aW1lci50eHQgICAgfCAgICA3ICsrDQo+ICBkcml2ZXJzL3NvYy9mc2wvbGF5ZXJzY2FwZS9m
dG1fYWxhcm0uYyAgICAgICAgICAgICB8ICAgOTIgKysrKysrKysrKysrKysrKysrLQ0KPiAgMiBm
aWxlcyBjaGFuZ2VkLCA5NCBpbnNlcnRpb25zKCspLCA1IGRlbGV0aW9ucygtKQ0KPiANCj4gZGlm
ZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy90aW1lci9mc2wsZnRt
LXRpbWVyLnR4dA0KPiBiL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy90aW1lci9m
c2wsZnRtLXRpbWVyLnR4dA0KPiBpbmRleCBhYThjNDAyLi4xNWVhZDU4IDEwMDY0NA0KPiAtLS0g
YS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdGltZXIvZnNsLGZ0bS10aW1lci50
eHQNCj4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3RpbWVyL2ZzbCxm
dG0tdGltZXIudHh0DQo+IEBAIC0zLDYgKzMsMTMgQEAgRnJlZXNjYWxlIEZsZXhUaW1lciBNb2R1
bGUgKEZUTSkgVGltZXIgIFJlcXVpcmVkDQo+IHByb3BlcnRpZXM6DQo+IA0KPiAgLSBjb21wYXRp
YmxlIDogc2hvdWxkIGJlICJmc2wsZnRtLXRpbWVyIg0KDQo+SGkgWWluZ2JvLA0KDQo+VGhpcyBp
cyBhIGNoYW5nZSB0aGF0IGJyZWFrcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCBub3QgYWNj
ZXB0YWJsZS4NCkhpIGxlbywNCg0KVGhpcyBwYXRjaCBpZiBJIGtlZXAgdGhlIGNoYW5nZSBhcyBp
bm5lciBwYXRjaCBhbmQgcHVzaCBpdCB0byBkYXNoLWxpbm51eCBidXQgSSB3aWxsIG5vdCBwdXNo
IGl0IHRvIHVwc3RyZWFtLCBJdCdzIG9rYXk/DQpBcyBmYXIgYXMgSSBrbm93LCB0aGVyZSB3YXMg
YSBvdGhlciBwYXRjaCBhbmQgZmlsZSBmb3IgcmVwbGFjZSB0aGUgZmlsZSBhbmQgdGhhdCB0aGUg
cGF0Y2ggaXMgYWxyZWFkeSBvbiB0aGUgdXBzdHJlYW0gDQpodHRwczovL3BhdGNod29yay5rZXJu
ZWwub3JnL3BhdGNoLzkzOTEyOTMvDQoNCj4gKyBQb3NzaWJsZSBjb21wYXRpYmxlcyBmb3IgQVJN
Og0KPiArICAgICAiZnNsLGxzMTAxMmEtZnRtIg0KPiArICAgICAiZnNsLGxzMTAyMWEtZnRtIg0K
PiArICAgICAiZnNsLGxzMTA0M2EtZnRtIg0KPiArICAgICAiZnNsLGxzMTA0NmEtZnRtIg0KPiAr
ICAgICAiZnNsLGxzMTA4OGEtZnRtIg0KPiArICAgICAiZnNsLGxzMjA4eGEtZnRtIg0KPiAgLSBy
ZWcgOiBTcGVjaWZpZXMgYmFzZSBwaHlzaWNhbCBhZGRyZXNzIGFuZCBzaXplIG9mIHRoZSByZWdp
c3RlciBzZXRzIGZvciB0aGUNCj4gICAgY2xvY2sgZXZlbnQgZGV2aWNlIGFuZCBjbG9jayBzb3Vy
Y2UgZGV2aWNlLg0KPiAgLSBpbnRlcnJ1cHRzIDogU2hvdWxkIGJlIHRoZSBjbG9jayBldmVudCBk
ZXZpY2UgaW50ZXJydXB0Lg0KPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zb2MvZnNsL2xheWVyc2Nh
cGUvZnRtX2FsYXJtLmMNCj4gYi9kcml2ZXJzL3NvYy9mc2wvbGF5ZXJzY2FwZS9mdG1fYWxhcm0u
Yw0KPiBpbmRleCA2Zjk4ODJmLi44MTFkY2ZhIDEwMDY0NA0KPiAtLS0gYS9kcml2ZXJzL3NvYy9m
c2wvbGF5ZXJzY2FwZS9mdG1fYWxhcm0uYw0KPiArKysgYi9kcml2ZXJzL3NvYy9mc2wvbGF5ZXJz
Y2FwZS9mdG1fYWxhcm0uYw0KDQo+VGhlcmUgaXMgbm8gc3VjaCBmaWxlIGluIHRoZSBtYWlubGlu
ZSBrZXJuZWwuICBTbyBpdCBsb29rcyBsaWtlIHRoZSBwYXRjaCBzZXQgaXMNCg0KPiBiYXNlZCBv
biBzb21lIGludGVybmFsIGdpdCByZXBvIGluc3RlYWQgb2YgdGhlIHVwc3RyZWFtIExpbnV4IGtl
cm5lbC4gIFRoaXMga2luZCBvZiBwYXRjaGVzDQoNCj4gc2hvdWxkbid0IGJlIHNlbnQgdG8gdGhl
IHVwc3RyZWFtIG1haWxpbmcgbGlzdCBmb3IgcmV2aWV3Lg0KDQo+UmVnYXJkcywNCg0KPkxlbw0K
VGhpcyBwYXRjaCB3aWxsIG5vdCB0byB1cHN0cmVhbS4NCg0KUmVnYXJkcywNCg0KWWluYm8uDQo=
^ permalink raw reply
* Re: [PATCH v3 4/4] powerpc/kbuild: move -mprofile-kernel check to Kconfig
From: kbuild test robot @ 2018-05-14 7:42 UTC (permalink / raw)
To: Nicholas Piggin
Cc: kbuild-all, linux-kbuild, Steven Rostedt, Masahiro Yamada,
linuxppc-dev, Nicholas Piggin
In-Reply-To: <20180514035228.21316-5-npiggin@gmail.com>
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-patches-for-new-Kconfig-language/20180514-120748
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
make.cross ARCH=powerpc defconfig
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:468: syntax error
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:467: invalid option
make[2]: *** [defconfig] Error 1
make[1]: *** [defconfig] Error 2
make: *** [sub-make] Error 2
--
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:468: syntax error
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:467: invalid option
make[2]: *** [oldconfig] Error 1
make[1]: *** [oldconfig] Error 2
make: *** [sub-make] Error 2
--
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:468: syntax error
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
arch/powerpc/Kconfig:467:warning: ignoring unsupported character '$'
>> arch/powerpc/Kconfig:467: invalid option
make[2]: *** [olddefconfig] Error 1
make[2]: Target 'oldnoconfig' not remade because of errors.
make[1]: *** [oldnoconfig] Error 2
make: *** [sub-make] Error 2
vim +468 arch/powerpc/Kconfig
e05c0e81 Kevin Hao 2013-07-16 443
3d72bbc4 Michael Neuling 2013-02-13 444 config PPC_TRANSACTIONAL_MEM
3d72bbc4 Michael Neuling 2013-02-13 445 bool "Transactional Memory support for POWERPC"
3d72bbc4 Michael Neuling 2013-02-13 446 depends on PPC_BOOK3S_64
3d72bbc4 Michael Neuling 2013-02-13 447 depends on SMP
7b37a123 Michael Neuling 2014-01-08 448 select ALTIVEC
7b37a123 Michael Neuling 2014-01-08 449 select VSX
3d72bbc4 Michael Neuling 2013-02-13 450 default n
3d72bbc4 Michael Neuling 2013-02-13 451 ---help---
3d72bbc4 Michael Neuling 2013-02-13 452 Support user-mode Transactional Memory on POWERPC.
3d72bbc4 Michael Neuling 2013-02-13 453
951eedeb Nicholas Piggin 2017-05-29 454 config LD_HEAD_STUB_CATCH
951eedeb Nicholas Piggin 2017-05-29 455 bool "Reserve 256 bytes to cope with linker stubs in HEAD text" if EXPERT
951eedeb Nicholas Piggin 2017-05-29 456 depends on PPC64
951eedeb Nicholas Piggin 2017-05-29 457 default n
951eedeb Nicholas Piggin 2017-05-29 458 help
951eedeb Nicholas Piggin 2017-05-29 459 Very large kernels can cause linker branch stubs to be generated by
951eedeb Nicholas Piggin 2017-05-29 460 code in head_64.S, which moves the head text sections out of their
951eedeb Nicholas Piggin 2017-05-29 461 specified location. This option can work around the problem.
951eedeb Nicholas Piggin 2017-05-29 462
951eedeb Nicholas Piggin 2017-05-29 463 If unsure, say "N".
951eedeb Nicholas Piggin 2017-05-29 464
8c50b72a Torsten Duwe 2016-03-03 465 config MPROFILE_KERNEL
8c50b72a Torsten Duwe 2016-03-03 466 depends on PPC64 && CPU_LITTLE_ENDIAN
53561d2c Nicholas Piggin 2018-05-14 @467 def_bool $(success $(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)
8c50b72a Torsten Duwe 2016-03-03 @468
:::::: The code at line 468 was first introduced by commit
:::::: 8c50b72a3b4f1f7cdfdfebd233b1cbd121262e65 powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel
:::::: TO: Torsten Duwe <duwe@lst.de>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH 2/3] hwmon: (ibmpowernv): Add support to read 64 bit sensors
From: Michael Ellerman @ 2018-05-14 7:11 UTC (permalink / raw)
To: Guenter Roeck, Shilpasri G Bhat
Cc: linux-kernel, linuxppc-dev, linux-hwmon, benh, paulus, jdelvare,
stewart
In-Reply-To: <20180509172926.GA20996@roeck-us.net>
Guenter Roeck <linux@roeck-us.net> writes:
> On Mon, May 07, 2018 at 03:55:37PM +0530, Shilpasri G Bhat wrote:
>> The firmware has supported for reading sensor values of size u32.
>> This patch adds support to use newer firmware functions which allows
>> to read the sensors of size u64.
>>
>> Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
>
> I won't apply for the time being since it depends on patch 1/3 which is
> outside hwmon.
Do you mind if I take the series via the powerpc tree?
cheers
^ permalink raw reply
* Re: [powerpc:merge 138/138] arch/powerpc/kernel/setup_64.c:354:2: error: implicit declaration of function 'this_cpu_enable_ftrace'; did you mean 'preempt_enable_notrace'?
From: Michael Ellerman @ 2018-05-14 7:10 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linuxppc-dev
In-Reply-To: <201805100608.5GVmAvCt%fengguang.wu@intel.com>
kbuild test robot <lkp@intel.com> writes:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
> head: 900be8ab1549359ba980cfb042a043128204a963
> commit: 900be8ab1549359ba980cfb042a043128204a963 [138/138] Automatic merge of branches 'master', 'next' and 'fixes' into merge
> config: powerpc-defconfig (attached as .config)
> compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 900be8ab1549359ba980cfb042a043128204a963
> # save the attached .config to linux build tree
> make.cross ARCH=powerpc
>
> All errors (new ones prefixed by >>):
>
> In file included from include/linux/ftrace.h:21:0,
> from arch/powerpc/include/asm/livepatch.h:23,
> from arch/powerpc/kernel/setup_64.c:67:
> arch/powerpc/include/asm/ftrace.h:2:0: error: unterminated #ifndef
> #ifndef _ASM_POWERPC_FTRACE
>
> arch/powerpc/kernel/setup_64.c: In function 'early_setup':
>>> arch/powerpc/kernel/setup_64.c:354:2: error: implicit declaration of function 'this_cpu_enable_ftrace'; did you mean 'preempt_enable_notrace'? [-Werror=implicit-function-declaration]
> this_cpu_enable_ftrace();
> ^~~~~~~~~~~~~~~~~~~~~~
> preempt_enable_notrace
> cc1: all warnings being treated as errors
> --
> In file included from arch/powerpc/kernel/smp.c:62:0:
> arch/powerpc/include/asm/ftrace.h:2:0: error: unterminated #ifndef
> #ifndef _ASM_POWERPC_FTRACE
This was caused by a bad merge by me. Fixed now.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus()
From: Madhavan Srinivasan @ 2018-05-14 6:47 UTC (permalink / raw)
To: Michael Neuling, Anju T Sudhakar, linuxppc-dev; +Cc: ppaidipe
In-Reply-To: <1526082337.11357.17.camel@neuling.org>
On Saturday 12 May 2018 05:15 AM, Michael Neuling wrote:
> On Fri, 2018-05-11 at 19:13 +0530, Anju T Sudhakar wrote:
>> Currently memory is allocated for core-imc based on cpu_present_mask, which
>> has
>> bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core)
>> as as array index to access the memory.
>> So in a system with guarded cores, since allocation happens based on
>> cpu_present_mask, (cpu number / threads per core) bounds the index and leads
>> to memory overflow.
>>
>> The issue is exposed in a guard test.
>> The guard test will make some CPU's as un-available to the system during boot
>> time as well as at runtime. So when the cpu is unavailable to the system
>> during
>> boot time, the memory allocation happens depending on the number of available
>> cpus. And when we access the memory using (cpu number / threads per core) as
>> the
>> index the system crashes due to memory overflow.
>>
>> Allocating memory for core-imc based on cpu_possible_mask, which has
>> bit 'cpu' set iff cpu is populatable, will fix this issue.
>>
>> Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
>> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Thanks, this should be:
>
> Cc: <stable@vger.kernel.org> # 4.14
Thanks for marking to stable. But it should go to 4.14+ stable releases.
Maddy
>> ---
>> arch/powerpc/perf/imc-pmu.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
>> index d7532e7..75fb23c 100644
>> --- a/arch/powerpc/perf/imc-pmu.c
>> +++ b/arch/powerpc/perf/imc-pmu.c
>> @@ -1146,7 +1146,7 @@ static int init_nest_pmu_ref(void)
>>
>> static void cleanup_all_core_imc_memory(void)
>> {
>> - int i, nr_cores = DIV_ROUND_UP(num_present_cpus(), threads_per_core);
>> + int i, nr_cores = DIV_ROUND_UP(num_possible_cpus(),
>> threads_per_core);
>> struct imc_mem_info *ptr = core_imc_pmu->mem_info;
>> int size = core_imc_pmu->counter_mem_size;
>>
>> @@ -1264,7 +1264,7 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct
>> device_node *parent,
>> if (!pmu_ptr->pmu.name)
>> return -ENOMEM;
>>
>> - nr_cores = DIV_ROUND_UP(num_present_cpus(),
>> threads_per_core);
>> + nr_cores = DIV_ROUND_UP(num_possible_cpus(),
>> threads_per_core);
>> pmu_ptr->mem_info = kcalloc(nr_cores, sizeof(struct
>> imc_mem_info),
>> GFP_KERNEL);
>>
^ permalink raw reply
* [PATCH] powerpc/cpu: nr_cpu_ids should be aligned on threads_per_core
From: Pingfan Liu @ 2018-05-14 6:13 UTC (permalink / raw)
To: linuxppc-dev
With p8 subcore mode, if nr_cpus is not aligned on threads_per_core,
then we will hit the following panic:
[ 0.310006] Unpacking initramfs...
[ 1.105015] Freeing initrd memory: 35968K
[ 1.105466] rtas_flash: no firmware flash support
[ 1.105688] Unable to handle kernel paging request for data at address 0x00001035
[ 1.105768] Faulting instruction address: 0xc000000000099bb8
[ 1.105837] Oops: Kernel access of bad area, sig: 11 [#1]
[ 1.105890] LE SMP NR_CPUS=2048 NUMA PowerNV
[ 1.105947] Modules linked in:
[ 1.105992] CPU: 8 PID: 11 Comm: migration/8 Not tainted 4.17.0-rc4+ #26
[ 1.106059] NIP: c000000000099bb8 LR: c0000000000ac554 CTR: c000000000099b70
[ 1.106139] REGS: c000000ff649f860 TRAP: 0380 Not tainted (4.17.0-rc4+)
[ 1.106205] MSR: 9000000000001033 <SF,HV,ME,IR,DR,RI,LE> CR: 28004022 XER: 00000000
[ 1.106293] CFAR: c0000000000ac550 SOFTE: 3
[ 1.106293] GPR00: c0000000000ac554 c000000ff649fae0 c0000000012e6d00 0000000000000060
[ 1.106293] GPR04: 0000000000000001 c0000000000ac914 9000000000001033 c000003fffffff80
[ 1.106293] GPR08: 0000000000000000 0000000000000001 0000000000000000 9000000000001003
[ 1.106293] GPR12: c000000000099b70 c000000001700000 c000000000141c28 c000000ffa201180
[ 1.106293] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 1.106293] GPR20: 0000000000000000 0000000000000000 0000000000000001 c000000fffd13840
[ 1.106293] GPR24: c000000fffd13838 0000000000000000 0000000000000001 0000000000000010
[ 1.106293] GPR28: 0000000000000008 0000000000000001 c000000001370548 000000000000000c
[ 1.106984] NIP [c000000000099bb8] icp_native_cause_ipi+0x48/0x70
[ 1.107053] LR [c0000000000ac554] pnv_cause_ipi+0x54/0x80
[ 1.107106] Call Trace:
[ 1.107137] [c000000ff649fae0] [c0000000000478b4] doorbell_try_core_ipi+0x74/0x90 (unreliable)
[ 1.107232] [c000000ff649fb10] [c0000000000ac554] pnv_cause_ipi+0x54/0x80
[ 1.107301] [c000000ff649fb40] [c00000000004ccfc] smp_muxed_ipi_message_pass+0x6c/0x90
[ 1.107384] [c000000ff649fb80] [c0000000000acbe8] cpu_do_split+0x2b8/0x2f0
[ 1.107453] [c000000ff649fbf0] [c0000000000acdb8] cpu_update_split_mode+0x68/0x204
[ 1.107536] [c000000ff649fc40] [c000000000204ab8] multi_cpu_stop+0x1c8/0x200
[ 1.107617] [c000000ff649fca0] [c000000000204eb4] cpu_stopper_thread+0x114/0x1f0
[ 1.107699] [c000000ff649fd60] [c000000000148650] smpboot_thread_fn+0x290/0x2a0
[ 1.107780] [c000000ff649fdc0] [c000000000141d84] kthread+0x164/0x1b0
[ 1.107850] [c000000ff649fe30] [c00000000000b628] ret_from_kernel_thread+0x5c/0xb4
[ 1.107929] Instruction dump:
[ 1.107971] 7c7f1b78 60000000 60000000 3d420004 394ab070 7be31f24 39200001 e90a0000
[ 1.108058] 3d42001b 394a2650 7d08182a 7d4a182a <99281035> 39000004 7c0004ac 990a000c
[ 1.108150] ---[ end trace 83dad19c162dc306 ]---
[ 1.110137]
[ 2.110227] Kernel panic - not syncing: Fatal exception
This is caused by that during subcore_init, it IPIs all cpu inside the core, but due to the limitation
imposed by nr_cpus, there are no mem allocated for percpu cpu_sibling_map.
To avoid a complicated fix, this patch just forces the nr_cpu_ids to be aligned on thread_per_code
at the cost of a bit more memory.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
---
arch/powerpc/kernel/prom.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9dbed48..358adb4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -315,6 +315,7 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
int len;
int found = -1;
int found_thread = 0;
+ unsigned int nr_cpus_aligned;
/* We are scanning "cpu" nodes only */
if (type == NULL || strcmp(type, "cpu") != 0)
@@ -361,7 +362,13 @@ static int __init early_init_dt_scan_cpus(unsigned long node,
/* Not the boot CPU */
if (found < 0)
return 0;
-
+ /* to work around p8 subcore mode */
+ nr_cpus_aligned = _ALIGN_UP(nr_cpu_ids, nthreads);
+ if (nr_cpus_aligned != nr_cpu_ids) {
+ pr_info("nr_cpus is forced to align up on threads_per_core,"
+ "from %u to %u\n", nr_cpu_ids, nr_cpus_aligned);
+ nr_cpu_ids = nr_cpus_aligned;
+ }
DBG("boot cpu: logical %d physical %d\n", found,
be32_to_cpu(intserv[found_thread]));
boot_cpuid = found;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 4/4] powerpc: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selected
From: Mathieu Malaterre @ 2018-05-14 6:06 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Masahiro Yamada, linux-arch, linuxppc-dev, linux-kbuild
In-Reply-To: <20180509130001.24276-5-npiggin@gmail.com>
On Wed, May 9, 2018 at 3:00 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
> This requires further changes to linker script to KEEP some tables
> and wildcard compiler generated sections into the right place. This
> includes pp32 modifications from Christophe Leroy.
>
> When compiling powernv_defconfig with this option, the resulting
> kernel is almost 400kB smaller (and still boots):
>
> text data bss dec filename
> 11827621 4810490 1341080 17979191 vmlinux
> 11752437 4598858 1338776 17690071 vmlinux.dcde
>
> Mathieu's numbers for custom Mac Mini G4 config has almost 200kB
Technically this is an oldconfig from debian original config file
(debian official powerpc kernel package)... tested on a mac mini g4.
> saving. It also had some increase in vmlinux size for as-yet
> unknown reasons.
>
> text data bss dec filename
> 7461457 2475122 1428064 11364643 vmlinux
> 7386425 2364370 1425432 11176227 vmlinux.dcde
>
> Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> [8xx]
> Tested-by: Mathieu Malaterre <malat@debian.org> [32-bit powermac]
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/kernel/vmlinux.lds.S | 22 +++++++++++-----------
> 2 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c32a181a7cbb..ee6dbe2efc8b 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -205,6 +205,7 @@ config PPC
> select HAVE_KPROBES
> select HAVE_KPROBES_ON_FTRACE
> select HAVE_KRETPROBES
> + select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
> select HAVE_MEMBLOCK
> select HAVE_MEMBLOCK_NODE_MAP
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index c8af90ff49f0..52a93cdd04bc 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -89,7 +89,7 @@ SECTIONS
> */
> .text BLOCK(0) : AT(ADDR(.text) - LOAD_OFFSET) {
> #ifdef CONFIG_LD_HEAD_STUB_CATCH
> - *(.linker_stub_catch);
> + KEEP(*(.linker_stub_catch));
> . = . ;
> #endif
>
> @@ -98,7 +98,7 @@ SECTIONS
> ALIGN_FUNCTION();
> #endif
> /* careful! __ftr_alt_* sections need to be close to .text */
> - *(.text.hot .text .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
> + *(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
> SCHED_TEXT
> CPUIDLE_TEXT
> LOCK_TEXT
> @@ -170,10 +170,10 @@ SECTIONS
> .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
> INIT_DATA
> __vtop_table_begin = .;
> - *(.vtop_fixup);
> + KEEP(*(.vtop_fixup));
> __vtop_table_end = .;
> __ptov_table_begin = .;
> - *(.ptov_fixup);
> + KEEP(*(.ptov_fixup));
> __ptov_table_end = .;
> }
>
> @@ -194,26 +194,26 @@ SECTIONS
> . = ALIGN(8);
> __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
> __start___ftr_fixup = .;
> - *(__ftr_fixup)
> + KEEP(*(__ftr_fixup))
> __stop___ftr_fixup = .;
> }
> . = ALIGN(8);
> __mmu_ftr_fixup : AT(ADDR(__mmu_ftr_fixup) - LOAD_OFFSET) {
> __start___mmu_ftr_fixup = .;
> - *(__mmu_ftr_fixup)
> + KEEP(*(__mmu_ftr_fixup))
> __stop___mmu_ftr_fixup = .;
> }
> . = ALIGN(8);
> __lwsync_fixup : AT(ADDR(__lwsync_fixup) - LOAD_OFFSET) {
> __start___lwsync_fixup = .;
> - *(__lwsync_fixup)
> + KEEP(*(__lwsync_fixup))
> __stop___lwsync_fixup = .;
> }
> #ifdef CONFIG_PPC64
> . = ALIGN(8);
> __fw_ftr_fixup : AT(ADDR(__fw_ftr_fixup) - LOAD_OFFSET) {
> __start___fw_ftr_fixup = .;
> - *(__fw_ftr_fixup)
> + KEEP(*(__fw_ftr_fixup))
> __stop___fw_ftr_fixup = .;
> }
> #endif
> @@ -226,7 +226,7 @@ SECTIONS
> . = ALIGN(8);
> .machine.desc : AT(ADDR(.machine.desc) - LOAD_OFFSET) {
> __machine_desc_start = . ;
> - *(.machine.desc)
> + KEEP(*(.machine.desc))
> __machine_desc_end = . ;
> }
> #ifdef CONFIG_RELOCATABLE
> @@ -274,7 +274,7 @@ SECTIONS
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> *(.data.rel*)
> - *(.sdata)
> + *(SDATA_MAIN)
> *(.sdata2)
> *(.got.plt) *(.got)
> *(.plt)
> @@ -289,7 +289,7 @@ SECTIONS
>
> .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
> __start_opd = .;
> - *(.opd)
> + KEEP(*(.opd))
> __end_opd = .;
> }
>
> --
> 2.17.0
>
^ 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