[PATCH bpf] bpf: fix default unprivileged allocation limit

in case of an architecture like powerpc64 which uses 64K as the default page size (i.e. CONFIG_PPC_64K_PAGES is set). So, instead of depending on the page size, use a constant value. Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations") Signed-off-by: Sa

[PATCH bpf] bpf: powerpc: fix broken uapi for BPF_PROG_TYPE_PERF_EVENT

ernel definitions of struct pt_regs") Signed-off-by: Sandipan Das --- arch/powerpc/include/asm/perf_event.h | 2 ++ arch/powerpc/include/uapi/asm/Kbuild | 1 - arch/powerpc/include/uapi/asm/bpf_perf_event.h | 9 + 3 files changed, 11 insertions(+), 1 deletion(-) create m

Re: [PATCH v2 bpf-next 2/7] ppc: bpf: implement jitting of BPF_ALU | BPF_ARSH | BPF_*

On 06/12/18 12:22 AM, Jiong Wang wrote: > This patch implements code-gen for BPF_ALU | BPF_ARSH | BPF_*. > > Cc: Naveen N. Rao > Cc: Sandipan Das > Signed-off-by: Jiong Wang > --- > arch/powerpc/include/asm/ppc-opcode.h | 2 ++ > arch/powerpc/net/bpf_jit.h

Re: [PATCH bpf-next 2/7] ppc: bpf: implement jitting of BPF_ALU | BPF_ARSH | BPF_*

Hi Jiong, On 05/12/18 2:25 AM, Jiong Wang wrote: > This patch implements code-gen for BPF_ALU | BPF_ARSH | BPF_*. > > Cc: Naveen N. Rao > Cc: Sandipan Das > Signed-off-by: Jiong Wang > --- [...] > diff --git a/arch/powerpc/net/bpf_jit_comp64.c > b/arch/powerpc/net/

Re: [PATCH bpf] bpf: powerpc64: optimize JIT passes for bpf function calls

Hi Daniel, On 03/12/18 6:18 PM, Daniel Borkmann wrote: > > Thanks for the patch, just to clarify, it's targeted at bpf-next and > not bpf, correct? > This patch is targeted at the bpf tree. This depends on commit e2c95a61656d ("bpf, ppc64: generalize fetching subprog into

Re: [PATCH bpf] bpf: fix bpf_prog_get_info_by_fd to return 0 func_lens for unpriv

hs of functions via syscall") forgot about doing so and therefore > returns the #elems of the user set up buffer which is incorrect. It > also needs to indicate a info.nr_jited_func_lens of zero. > > Fixes: 815581c11cc2 ("bpf: get JITed image lengths of functions via syscall"

Re: [PATCH bpf-next v4 02/10] bpf: powerpc64: pad function address loads with NOPs

On 05/24/2018 01:04 PM, Daniel Borkmann wrote: > On 05/24/2018 08:56 AM, Sandipan Das wrote: >> For multi-function programs, loading the address of a callee >> function to a register requires emitting instructions whose >> count varies from one to five depending on the nat

[PATCH bpf-next v4 05/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Move new fields to t

[PATCH bpf-next v4 03/10] bpf: powerpc64: add JIT support for multi-function programs

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 auxiliary data of the caller by using the off field as an index. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Fix memory leak for ji

[PATCH bpf-next v4 07/10] bpf: fix multi-function JITed dump obtained via syscall

0: nop 4: nop 8: mflrr0 c: std r0,16(r1) 10: stdur1,-112(r1) 14: std r31,104(r1) 18: addir31,r1,48 1c: li r3,10 ... Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v4: - If the image allocated in use

[PATCH bpf-next v4 08/10] bpf: get JITed image lengths of functions via syscall

applications like bpftool to split up the contiguous JITed dump, also obtained via the system call, into more relatable chunks corresponding to each function. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- include/uapi/linux/bpf.h | 2 ++ kernel/bpf/syscall.c

[PATCH bpf-next v4 02/10] bpf: powerpc64: pad function address loads with NOPs

required to load this address may vary from what was previously generated. This can make the JITed image grow or shrink. To avoid this, we should generate a constant five-instruction when loading function addresses by padding the optimized load sequence with NOPs. Signed-off-by: Sandipan Das <sa

[PATCH bpf-next v4 04/10] bpf: get kernel symbol addresses via syscall

of a callee's corresponding symbol by using the imm field as an index for the list of kernel symbol addresses now available from the program info. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Co

[PATCH bpf-next v4 06/10] tools: bpftool: resolve calls without using imm field

for this list to lookup a callee's symbol's address and resolve its name. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> Reviewed-by: Jakub Kicinski <jakub.kicin...@netronome.com> --- v3: - Avoid using redundant pointers. - Fi

[PATCH bpf-next v4 09/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the JITed image lengths of each function in a multi-function program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/include/uapi/linux/bpf.h | 2 ++ 1 file chan

[PATCH bpf-next v4 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

t;: ["%rbp" ] },{ ... },{ "pc": "0x71", "operation": "retq", "operands": [null ] } ] },{ "name&

[PATCH bpf-next v4 00/10] bpf: enhancements for multi-function programs

after the last pass due to the way the instruction sequence used to load a callee's address maybe optimized. - Make additional changes to the bpf system call and bpftool to make multi-function JITed dumps easier to correlate. v2: - Incorporate review comments from Jakub. Sandipan Das

[PATCH bpf-next v4 01/10] bpf: support 64-bit offsets for bpf function calls

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 <sandi...@linux.vnet.ibm.com> --- kern

Re: [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

On 05/23/2018 07:20 PM, Daniel Borkmann wrote: > On 05/23/2018 12:37 PM, Sandipan Das wrote: > [...] >> Other than that, for powerpc64, there is a problem with the way the >> binutils disassembler code (in "opcodes/ppc-dis.c") passes arguments >

Re: [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

On 05/23/2018 02:38 PM, Daniel Borkmann wrote: > On 05/22/2018 09:55 PM, Jakub Kicinski wrote: >> On Tue, 22 May 2018 22:46:13 +0530, Sandipan Das wrote: >>> + if (info.nr_jited_func_lens && info.jited_func_lens) { >>> +

[PATCH bpf-next v3 01/10] bpf: support 64-bit offsets for bpf function calls

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 <sandi...@linux.vnet.ibm.com> --- kern

[PATCH bpf-next v3 03/10] bpf: powerpc64: add JIT support for multi-function programs

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 auxiliary data of the caller by using the off field as an index. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Fix memory leak for ji

[PATCH bpf-next v3 02/10] bpf: powerpc64: pad function address loads with NOPs

required to load this address may vary from what was previously generated. This can make the JITed image grow or shrink. To avoid this, we should generate a constant five-instruction when loading function addresses by padding the optimized load sequence with NOPs. Signed-off-by: Sandipan Das <sa

[PATCH bpf-next v3 00/10] bpf: enhancements for multi-function programs

changes to the bpf system call and bpftool to make multi-function JITed dumps easier to correlate. v2: - Incorporate review comments from Jakub. Sandipan Das (10): bpf: support 64-bit offsets for bpf function calls bpf: powerpc64: pad function address loads with NOPs bpf: powerpc64: add JIT

[PATCH bpf-next v3 04/10] bpf: get kernel symbol addresses via syscall

of a callee's corresponding symbol by using the imm field as an index for the list of kernel symbol addresses now available from the program info. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Co

[PATCH bpf-next v3 06/10] tools: bpftool: resolve calls without using imm field

for this list to lookup a callee's symbol's address and resolve its name. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Avoid using redundant pointers. - Fix indentation. v2: - Order variables from longest to shortest.

[PATCH bpf-next v3 07/10] bpf: fix multi-function JITed dump obtained via syscall

0: nop 4: nop 8: mflrr0 c: std r0,16(r1) 10: stdur1,-112(r1) 14: std r31,104(r1) 18: addir31,r1,48 1c: li r3,10 ... Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- kernel/bpf/syscall.

[PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps

a8: mr r3,r8 ac: blr bpf_prog_196af774a3477707_F: 0: nop 4: nop 8: mflrr0 c: std r0,16(r1) 10: stdur1,-112(r1) 14: std r31,104(r1) ... 88: mr r3,r8 8c: blr Signed-off-by: Sandipan Das

[PATCH bpf-next v3 09/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the JITed image lengths of each function in a multi-function program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/include/uapi/linux/bpf.h | 2 ++ 1 file chan

[PATCH bpf-next v3 08/10] bpf: get JITed image lengths of functions via syscall

applications like bpftool to split up the contiguous JITed dump, also obtained via the system call, into more relatable chunks corresponding to each function. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- include/uapi/linux/bpf.h | 2 ++ kernel/bpf/syscall.c

[PATCH bpf-next v3 05/10] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v3: - Move new fields to t

Re: [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall

Hi Daniel, On 05/18/2018 09:21 PM, Daniel Borkmann wrote: > On 05/18/2018 02:50 PM, Sandipan Das wrote: >> Currently, for multi-function programs, we cannot get the JITed >> instructions using the bpf system call's BPF_OBJ_GET_INFO_BY_FD >> command. Because of

Re: [PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls

On 05/18/2018 08:45 PM, Daniel Borkmann wrote: > On 05/18/2018 02:50 PM, Sandipan Das wrote: >> 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

[PATCH bpf v2 4/6] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a JITed program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/include/uapi/linux/bpf

[PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs

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 <sandi...@linux.vnet.ibm.com> --- arch/powerpc/net/bpf_jit_co

[PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall

0: nop 4: nop 8: mflrr0 c: std r0,16(r1) 10: stdur1,-112(r1) 14: std r31,104(r1) 18: addir31,r1,48 1c: li r3,10 ... Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- kernel/bpf/syscall.

[PATCH bpf v2 3/6] bpf: get kernel symbol addresses via syscall

of a callee's corresponding symbol by using the imm field as an index for the list of kernel symbol addresses now available from the program info. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- include/uapi

[PATCH bpf v2 5/6] tools: bpftool: resolve calls without using imm field

for this list to lookup a callee's symbol's address and resolve its name. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v2: - Order variables from longest to shortest - Make sure that ksyms_ptr and ksyms_len are always

[PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls

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 <sandi...@linux.vnet.ibm.com> --- kern

[PATCH bpf v2 0/6] bpf: enhancements for multi-function programs

from the bpf system call. v2: - Incorporate review comments from Jakub Sandipan Das (6): bpf: support 64-bit offsets for bpf function calls bpf: powerpc64: add JIT support for multi-function programs bpf: get kernel symbol addresses via syscall tools: bpf: sync bpf uapi header tools

Re: [PATCH bpf 5/6] tools: bpftool: resolve calls without using imm field

Hi Jakub, On 05/18/2018 12:21 AM, Jakub Kicinski wrote: > On Thu, 17 May 2018 12:05:47 +0530, Sandipan Das wrote: >> 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

[PATCH bpf 2/6] bpf: powerpc64: add JIT support for multi-function programs

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 <sandi...@linux.vnet.ibm.com> --- arch/powerpc/net/bpf_jit_co

[PATCH bpf 1/6] bpf: support 64-bit offsets for bpf function calls

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 <sandi...@linux.vnet.ibm.com> --- kern

[PATCH bpf 4/6] tools: bpf: sync bpf uapi header

Syncing the bpf.h uapi header with tools so that struct bpf_prog_info has the two new fields for passing on the addresses of the kernel symbols corresponding to each function in a JITed program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/include/uapi/linux/bpf

[PATCH bpf 6/6] bpf: fix JITed dump for multi-function programs via syscall

0: nop 4: nop 8: mflrr0 c: std r0,16(r1) 10: stdur1,-112(r1) 14: std r31,104(r1) 18: addir31,r1,48 1c: li r3,10 ... Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- kernel/bpf/syscall.

[PATCH bpf 3/6] bpf: get kernel symbol addresses via syscall

of a callee's corresponding symbol by using the imm field as an index for the list of kernel symbol addresses now available from the program info. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- include/uapi

[PATCH bpf 0/6] bpf: enhancements for multi-function programs

from the bpf system call. Sandipan Das (6): bpf: support 64-bit offsets for bpf function calls bpf: powerpc64: add JIT support for multi-function programs bpf: get kernel symbol addresses via syscall tools: bpf: sync bpf uapi header tools: bpftool: resolve calls without using imm

[PATCH bpf 5/6] tools: bpftool: resolve calls without using imm field

for this list to lookup a callee's symbol's address and resolve its name. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/bpf/bpftool/prog.c | 31 +++ tools/bpf/bpftool/xlated_d

[RFC][PATCH bpf v3 3/5] bpf: get JITed function addresses via syscall

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 <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- include/uapi/linu

[RFC][PATCH bpf v3 2/5] bpf: powerpc64: add JIT support for multi-function programs

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 <sandi...@linux.vnet.ibm.com> --- v3: Mention briefly abo

[RFC][PATCH bpf v3 4/5] tools: bpf: sync bpf uapi header

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 <sandi...@linux.vnet.ibm.com> --- tools/include/uapi/linux/bpf.h | 2 ++ 1 file changed, 2 inse

[RFC][PATCH bpf v3 1/5] bpf: allow 64-bit offsets for bpf function calls

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 <sandi...@linux.vnet.ibm.com> --- v3: Rephrase

[RFC][PATCH bpf v3 5/5] tools: bpftool: resolve call addresses without using imm field

for this list to lookup a callee's symbol's address and resolve its name. Suggested-by: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- tools/bpf/bpftool/prog.c | 33 + tools/bpf/bpftool/xlated_d

[RFC][PATCH bpf] tools: bpftool: Fix tags for bpf-to-bpf calls

) r0 = 2 4: (95) exit With this patch, it will look like this: 0: (85) call pc+2#bpf_prog_8f85936f29a7790a+3 1: (b7) r0 = 1 2: (95) exit 3: (b7) r0 = 2 4: (95) exit where 8f85936f29a7790a is the tag of the bpf program and 3 is the offset to the start of the subprog from t

[RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls

nsn as a way to index into aux->func and also set aux->func_cnt so that this can be used for performing basic upper bound checks for the off field. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v2: Make aux->func point to the list of functions determined by the ve

[RFC][PATCH bpf v2 2/2] bpf: powerpc64: add JIT support for multi-function programs

is performed. Since it is seen that the offsets may be as large as 64 bits for powerpc64, we use the aux data associated with each caller to get the correct branch target address rather than using the imm field of the BPF_CALL instruction. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- v

Re: [RFC][PATCH bpf 1/2] bpf: allow 64-bit offsets for bpf function calls

On 02/10/2018 06:08 AM, Alexei Starovoitov wrote: > On 2/9/18 8:54 AM, Naveen N. Rao wrote: >> Naveen N. Rao wrote: >>> Alexei Starovoitov wrote: >>>> On 2/8/18 4:03 AM, Sandipan Das wrote: >>>>> The imm field of a bpf_insn is a signed 32-bit intege

[RFC][PATCH bpf 2/2] bpf: powerpc64: add JIT support for multi-function programs

is performed. Since it is seen that the offsets may be as large as 64 bits for powerpc64, we use the aux data associated with each caller to get the correct branch target address rather than using the imm field of the BPF_CALL instruction. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> ---

[RFC][PATCH bpf 1/2] bpf: allow 64-bit offsets for bpf function calls

this cannot be accomodated in the imm field without truncation. To resolve this, we additionally use the aux data within each bpf_prog associated with the caller functions to store the addresses of their respective callees. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- kern

Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

Hi Alexei, Naveen, On 11/04/2017 11:01 PM, Naveen N. Rao wrote: > > I think the offsets described in dwarf were incorrect with > CONFIG_GCC_PLUGIN_RANDSTRUCT, but I'll let Sandipan confirm that. > I think that the offsets described in dwarf are probably incorrect when

[RFC PATCH] bpf: Add helpers to read useful task_struct members

To avoid this, we add new BPF helpers that read the correct values for some of the important task_struct members such as pid, tgid, comm and flags which are extensively used in BPF-based analysis tools such as bcc. Since these helpers are built with GCC, they use the correct offsets when refer

[PATCH 1/1] bpf: take advantage of stack_depth tracking in powerpc JIT

Take advantage of stack_depth tracking, originally introduced for x64, in powerpc JIT as well. Round up allocated stack by 16 bytes to make sure it stays aligned for functions called from JITed bpf program. Signed-off-by: Sandipan Das <sandi...@linux.vnet.ibm.com> --- arch/powerpc/net/bpf