From: Sandipan Das <sandipan@linux.vnet.ibm.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: ast@kernel.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, naveen.n.rao@linux.vnet.ibm.com,
mpe@ellerman.id.au, jakub.kicinski@netronome.com
Subject: Re: [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall
Date: Tue, 22 May 2018 01:12:14 +0530 [thread overview]
Message-ID: <57a3df63-f533-0dee-3fb8-621c0ba51968@linux.vnet.ibm.com> (raw)
In-Reply-To: <654d4424-ad99-2b5e-dcbf-9e352aec75d6@iogearbox.net>
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 this, userspace tools such as bpftool fail
>> to identify a multi-function program as being JITed or not.
>>
>> With the JIT enabled and the test program running, this can be
>> verified as follows:
>>
>> # cat /proc/sys/net/core/bpf_jit_enable
>> 1
>>
>> Before applying this patch:
>>
>> # bpftool prog list
>> 1: kprobe name foo tag b811aab41a39ad3d gpl
>> loaded_at 2018-05-16T11:43:38+0530 uid 0
>> xlated 216B not jited memlock 65536B
>> ...
>>
>> # bpftool prog dump jited id 1
>> no instructions returned
>>
>> After applying this patch:
>>
>> # bpftool prog list
>> 1: kprobe name foo tag b811aab41a39ad3d gpl
>> loaded_at 2018-05-16T12:13:01+0530 uid 0
>> xlated 216B jited 308B memlock 65536B
>> ...
>
> That's really nice! One comment inline below:
>
>> # bpftool prog dump jited id 1
>> 0: nop
>> 4: nop
>> 8: mflr r0
>> c: std r0,16(r1)
>> 10: stdu r1,-112(r1)
>> 14: std r31,104(r1)
>> 18: addi r31,r1,48
>> 1c: li r3,10
>> ...
>>
>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
>> ---
>> kernel/bpf/syscall.c | 38 ++++++++++++++++++++++++++++++++------
>> 1 file changed, 32 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index 54a72fafe57c..2430d159078c 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -1896,7 +1896,7 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> struct bpf_prog_info info = {};
>> u32 info_len = attr->info.info_len;
>> char __user *uinsns;
>> - u32 ulen;
>> + u32 ulen, i;
>> int err;
>>
>> err = check_uarg_tail_zero(uinfo, sizeof(info), info_len);
>> @@ -1922,7 +1922,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> ulen = min_t(u32, info.nr_map_ids, ulen);
>> if (ulen) {
>> u32 __user *user_map_ids = u64_to_user_ptr(info.map_ids);
>> - u32 i;
>>
>> for (i = 0; i < ulen; i++)
>> if (put_user(prog->aux->used_maps[i]->id,
>> @@ -1970,13 +1969,41 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> * for offload.
>> */
>> ulen = info.jited_prog_len;
>> - info.jited_prog_len = prog->jited_len;
>> + if (prog->aux->func_cnt) {
>> + info.jited_prog_len = 0;
>> + for (i = 0; i < prog->aux->func_cnt; i++)
>> + info.jited_prog_len += prog->aux->func[i]->jited_len;
>> + } else {
>> + info.jited_prog_len = prog->jited_len;
>> + }
>> +
>> if (info.jited_prog_len && ulen) {
>> if (bpf_dump_raw_ok()) {
>> uinsns = u64_to_user_ptr(info.jited_prog_insns);
>> ulen = min_t(u32, info.jited_prog_len, ulen);
>> - if (copy_to_user(uinsns, prog->bpf_func, ulen))
>> - return -EFAULT;
>> +
>> + /* for multi-function programs, copy the JITed
>> + * instructions for all the functions
>> + */
>> + if (prog->aux->func_cnt) {
>> + u32 len, free;
>> + u8 *img;
>> +
>> + free = ulen;
>> + for (i = 0; i < prog->aux->func_cnt; i++) {
>> + len = prog->aux->func[i]->jited_len;
>> + img = (u8 *) prog->aux->func[i]->bpf_func;
>> + if (len > free)
>> + break;
>> + if (copy_to_user(uinsns, img, len))
>> + return -EFAULT;
>> + uinsns += len;
>> + free -= len;
>
> Is there any way we can introduce a delimiter between the different
> images such that they could be more easily correlated with the call
> from the main (or other sub-)program instead of having one contiguous
> dump blob?
>
Can we have another member in bpf_prog_info that points to a list of the lengths of the
JITed images for each subprogram? We can use this information to split up the dump.
- Sandipan
>> + }
>> + } else {
>> + if (copy_to_user(uinsns, prog->bpf_func, ulen))
>> + return -EFAULT;
>> + }
>> } else {
>> info.jited_prog_insns = 0;
>> }
>> @@ -1987,7 +2014,6 @@ static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
>> if (info.nr_jited_ksyms && ulen) {
>> u64 __user *user_jited_ksyms = u64_to_user_ptr(info.jited_ksyms);
>> ulong ksym_addr;
>> - u32 i;
>>
>> /* copy the address of the kernel symbol corresponding to
>> * each function
>>
>
>
next prev parent reply other threads:[~2018-05-21 19:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-18 12:50 [PATCH bpf v2 0/6] bpf: enhancements for multi-function programs Sandipan Das
2018-05-18 12:50 ` [PATCH bpf v2 1/6] bpf: support 64-bit offsets for bpf function calls Sandipan Das
2018-05-18 15:15 ` Daniel Borkmann
2018-05-18 16:17 ` Sandipan Das
2018-05-18 12:50 ` [PATCH bpf v2 2/6] bpf: powerpc64: add JIT support for multi-function programs Sandipan Das
2018-05-18 15:30 ` Daniel Borkmann
2018-05-18 16:05 ` Naveen N. Rao
2018-05-18 16:08 ` Daniel Borkmann
2018-05-18 12:50 ` [PATCH bpf v2 3/6] bpf: get kernel symbol addresses via syscall Sandipan Das
2018-05-18 15:43 ` Daniel Borkmann
2018-05-18 12:50 ` [PATCH bpf v2 4/6] tools: bpf: sync bpf uapi header Sandipan Das
2018-05-18 12:50 ` [PATCH bpf v2 5/6] tools: bpftool: resolve calls without using imm field Sandipan Das
2018-05-18 19:55 ` Jakub Kicinski
2018-05-18 12:50 ` [PATCH bpf v2 6/6] bpf: fix JITed dump for multi-function programs via syscall Sandipan Das
2018-05-18 15:51 ` Daniel Borkmann
2018-05-21 19:42 ` Sandipan Das [this message]
2018-05-22 8:54 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57a3df63-f533-0dee-3fb8-621c0ba51968@linux.vnet.ibm.com \
--to=sandipan@linux.vnet.ibm.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=jakub.kicinski@netronome.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).